Two Atomic modules

eriatarka Joined: 11/06/07 Posts: 11

Posted: 01/26/10 12:24:06 It seems there are currently two Atomic modules in Tango trunk, tango.core.sync.Atomic and tango.core.Atomic, the latter being the older one and apparently deprecated or about to become so? However, the newer sync.Atomic exports much less functionality to the world and, as far as I can tell, does not permit implementing a lock-free ring buffer with it. (It provides only LL or SS memory barriers, but no mixed or full ones.) So why are there two modules, and is it ok to use the older, richer one for future-proof code?

Author	Message
eriatarka Joined: 11/06/07 Posts: 11	Posted: 01/26/10 12:31:46 Forgot to mention: the newer module seems to use the [lsm]fence opcodes, which AFAIK are only supported on CPUs which have SSE2. What about older CPUs, e.g. pre-Athlon64 AMDs?
kris Joined: 03/27/04 Posts: 581	Posted: 02/01/10 04:07:25 there's only one now :) The issue is that the one currently in tango.core is really slow to compile (for some reason), and the more recent attempt has too much call overhead (so it was removed). If you have some ideas on a compromise, then by all means please let us know
fawzi Joined: 02/20/08 Posts: 23	Posted: 02/10/10 19:32:28 Well if support on those old cpus is an issue one could use for example even cpuid on them, some version magic would then be needed. I am not sure about is needed for lock-free ring buffer, but all barriers should be available in the new one, maybe on some platform a stronger barrier than the requested one is enforced, but that should not be a problem. I don't think that the old module did really enforce the barriers it did claim to enforce. I wrote the sync.Atomic module but it was not really accepted as the "new" so I moved its development to http://github.com/fawzi/blip/blob/master/blip/sync/Atomic.d