handling shared objects

[Steven Schveighoffer]

On 11/26/18 10:37 AM, Alex wrote:
> On Monday, 26 November 2018 at 15:26:43 UTC, Steven Schveighoffer wrote:
>>
>> 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.
> 
> How to do this, if parts of the state are statically saved in a type?

For instance, with your toy example, instead of saving the D[] as a 
static instance to share with all threads, use idup to make a complete 
copy, and then send that array directly to the new thread via spawn. 
When the result is done, instead of sending a bool to say it's complete, 
send the answer.

Sending an immutable copy is the easiest way to ensure you have no 
races. It may be more expensive than you want to make a deep copy of 
something, but probably less expensive than the headache of creating a 
non-debuggable monster race condition.

> 
>> 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.
>>
> 
> Ah... ok. But then, I will prefer to mark the appropriate parts as 
> shared, I think...

Right :)

Threading is always very difficult to get right, and usually very 
difficult to find errors when you get it wrong. I remember working with 
pthreads about 20 years ago in a C++ project, and having a data race 
that caused a hang once every *2 weeks*. It took insane amounts of 
printouts and logging to figure out exactly why it happened (and the 
cycle was 2 weeks roughly), and the cause was (I think, not 100% sure) a 
place where a lock should have been but wasn't used.

-Steve