Better implementation of IAtomicArray

[halgari]

There really isn't any reason to have IAtomicArray. On the JVM we have a bad situation since we don't have memory barriers, and so there is no way to force the CPU to flush all data written to the state array. The situation on the CLR is much better:

For this CLR port I recommend switching away from an atomic array to a Object[]. All you need to do then is a call to Thread.MemoryBarrier() on the exit of every loop (see line 923 in ioc_macros.clj). This should actually be pretty fast since the array can be held purely in the cache until it's flushed each time the state machine is paused.

[dmiller]

Thanks for the suggestion. Thanks just for looking, for that matter.

I wonder if there are other places within ClojureCLR itself where some uses if IAtomicXXX could be replaced. For the most part, I just translated without spending a lot of time thinking about advantages the CLR might possess.

-David

On Wed, Feb 19, 2014 at 11:32 AM, Timothy Baldridge < [email protected]> wrote:

There really isn't any reason to have IAtomicArray. On the JVM we have a bad situation since we don't have memory barriers, and so there is no way to force the CPU to flush all data written to the state array. The situation on the CLR is much better:

For this CLR port I recommend switching away from an atomic array to a Object[]. All you need to do then is a call to Thread.MemoryBarrier() on the exit of very loop. This should actually be pretty fast since the array can be held purely in the cache until it's flushed each time the state machine is paused.

Reply to this email directly or view it on GitHubhttps://github.com/dmiller/clr.core.async/issues/1 .