handling shared objects

[Steven Schveighoffer]

On 11/26/18 10:16 AM, Alex wrote:
> On Monday, 26 November 2018 at 14:28:33 UTC, Steven Schveighoffer wrote:

>> A static member is stored per thread. If you want a global that's 
>> shared between all threads, you need to make it shared. But the result 
>> may not be what you are looking for, shared can cause difficulty if 
>> your code wasn't written to deal with it (and a lot of code isn't).
> 
> Well, the only reason I use multithreading is this:
> https://forum.dlang.org/thread/cfrtilrtbahollmazzfv@forum.dlang.org
> 
> So, even if my code is not really shared designed, this doesn't matter, 
> as I wait for "the other" thread to end (or interrupt it). So, marking 
> the model as shared is already a workaround, for being able to pass it 
> to another thread, which I don't really need. However, now, if also all 
> components of the model have to be marked shared, the workaround has to 
> grow and expands over all components (?). This is the reason for this 
> question...
> 

Well, if you want to run calculations in another thread, then send the 
result back to the original, you may be better off sending the state 
needed for the calculation to the worker thread, and receiving the 
result back via the messaging system. It's really hard to know the 
requirements with such toy examples, so maybe that's not workable for you.

What it seems like you need is a way to run the calculations in a 
separate thread. But with multiple threads comes all the dangers of 
concurrency and races. So you have to be very careful about how you 
design this.

At this point, std.concurrency does not have the ability to safely pass 
mutable data to another thread without it being shared.

Note that if you want to do it without safety in place, you can use the 
Thread class in core.thread which has no requirements for data to be 
immutable or shared. But you have to be even more careful about how you 
access the data.

-Steve