Unofficial wish list status.(Jul 2008)

[Simen Kjaeraas]

> Walter Bright wrote:
>
>> Yes, but the onus will be on you (the programmer) to prevent data races  
>> and
>> do proper synchronization.
>
> In the scenario described, the main thread initialises the array of  
> data. Then,
> non-overlapping slices of that are portioned out to N worker threads.  
> Only one
> thread ever modifies any given segment. When the worker threads are  
> complete,
> the 'results' are left in the original array available in its entirety  
> only to
> the main thread.
>
>> You have to be very wary of cache effects when
>> writing data in one thread and expecting to see it in another.
>
> Are you saying that there is some combination of OS and/or hardware L1/L2
> caching that would allow one thread to read a memory location  
> (previously)
> modified by another thread, and see 'old data'?
>
> Cos if you are, its a deeply serious bug that if its not already very  
> well
> documented by the OS writer or hardware manufacturers, then here's your  
> chance
> to get slashdotted (and diggited and redited etc. all concurrently) as  
> the
> discoveerer of a fatel processor flaw.

I don't think that's exactly what he means. If I understand things
correctly, if one thread is going to read something, that something
might be put in cache /before/ the other thread writes its data there.
So yes, it is previously written, at the time the read 'should' take
place.

-- Simen