handling shared objects

[Alex]

On Monday, 26 November 2018 at 14:28:33 UTC, Steven Schveighoffer 
wrote:
>> Some problems arose:
>> 1. Obviously, this is not the case, as the output is 
>> different, depending on the thread I start the model function.
>
> Yes, unless you declare the model to be shared, there is a copy 
> made for each thread, independently managed.
>
>> 2. If I declare the model object inside the main, the compiler 
>> aborts with the message "Aliases to mutable thread-local data 
>> not allowed."
>
> Right, because you are not allowed to pass unshared data 
> between threads.
>
>> 3. If I mark the S instance as shared, it works. But I didn't 
>> intend to do this... Is this really how it meant to be?
>
> Let's go over how the data is actually laid out:
>
> Model has NO data in it, so it doesn't really matter if it's 
> shared or not.
>
> S has a single array of element type D's. There is no static 
> data in S, so it has no static state (only instance state).
>
> D has a single size_t, which is thread-local,

especially, the size_t is local to an instance of D.

> but has a static instance of S in the TYPE.

Right, because to work properly a D instance has to know about 
the D's in the array of S

> There is not a copy of an S for each D, just a single copy for 
> each THREAD. If you make this shared, it's a shared copy for 
> all threads. This means the array inside the shared S will be 
> shared between all threads too.

This is the point where my headaches begin: I do not need this 
level of sharedness, but I don't really care.

>
> What happens when you spawn a new thread is that the 
> thread-local copy of m is created with Model.init (but it has 
> no data, so it's not important). A thread-local copy of D.s is 
> created with S.init (so an empty array). The reason your 
> assignment of length in main doesn't work is because the init 
> value is used, not the current value from the main thread.
>
> So yes, you need to make it shared to have the sub-thread see 
> the changes, if that's what you are after.
>
>> As I'm writing the model object as well as all of its 
>> compartments, I can do almost everything... but what I to 
>> avoid is to declare the instances of compartments inside the 
>> model:
>> They are stored locally to their modules and the single 
>> elements of them have to know about the compound objects, like 
>> with the D and S structs shown.
>
> 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...

>
> -Steve