[dmd-concurrency] draft 7
Sean Kelly
sean at invisibleduck.org
Tue Feb 2 15:06:59 PST 2010
On Feb 2, 2010, at 12:52 PM, Fawzi Mohamed wrote:
>
> On 2-feb-10, at 18:50, Sean Kelly wrote:
>
>> On Feb 2, 2010, at 6:04 AM, Fawzi Mohamed wrote:
>
>>> By the way I found the atomic module in tango difficult to use correctly (maybe I had not understood it), and I rewrote it.
>>
>> What problems did you have?
>
> yes, I don't remember exactly, but I found the terminology unfamiliar to me (hoist-store barrier and hoist-load), and I did not see the two barriers I wanted (basically the one you tipically need are (store-store, and load-load, order stores wrt. stores and order loads wrt loads, what I call write and read barriers).
> Typically I want either a flag or something like that, and I like the barriers to be "hidden" in the operation I call.
> I don't want to have to think if the barriers has to be before or after the operation each time I call, some seemed at the wrong place to me.
> When writing a flag for example the write barrier is before writing the flag, whereas when reading the read barrier goes after reading the flag.
> Whereas the old module had this (opaque to me) terminology and you sort of had to pass it to each call, furthermore the barrier operations themselves looked wrong to me (lock is not enough).
I think LOCK is enough. The FENCE instructions didn't apply to normal memory operations until very recently--they had always been for streaming operations only. A LOCK operation is equivalent to an MFENCE on the operation itself. On platforms where finer-grained barriers are available, assume that they are in the places you expect.
> It is fully possible that I simply did not understand how it was supposed to work, in any case I find (clearly ;) my version more clear, and I can use it correctly.
I'll have to give it another look. Last time I checked the API didn't seem to have changed very much.
More information about the dmd-concurrency
mailing list