Volatile semantics for #get, #set, and #swap #4
Conversation
Previously, there was a preprocessor conditional directive in atomic_reference.c which checked for HAVE_GCC_CAS. It's gone now. So there is no reason to waste time while compiling.
alexdowad
changed the title
|
@alexdowad Thank you for this update. Would you mind submitting this PR to the concurrent-ruby repo, too? This gem has been merged into concurrent-ruby, and @headius has indicated he will end-of-life ruby-atomic. We'll need to make this change in the other gem. |
|
@jdantonio, so in the future, the |
|
That is what @headius had previously indicated. He originally offered to merge both ruby-atomic and thread_safe into concurrent-ruby in May of this year during this discussion. In the ensuing discussion he stated that he wanted to do one more release of ruby-atomic that defers to concurrent-ruby. We've done the initial merge of ruby-atomic and have released several RC builds of concurrent-ruby with the merged code. We are on track for a full release later this week. As far as I know @headius still plans to end-of-life ruby-atomic once we release concurrent-ruby 0.7.0, but that is entirely his decision. He and I will both be attending the Steel City Ruby conference next weekend. I expect we will talk more then. |
Volatile semantics for #get, #set, and #swap
In Java, reads/writes to
volatilevariables provide definite, clearly-defined guarantees for memory visibility and "happens-before" relationships. Ruby (sadly) doesn't specify what memory-model semantics reads and writes to variables have. Basically, it does whatever the underlying compiler and hardware do "by default".The
atomicgem has a great opportunity to make things right. These patches giveAtomic#get,#set, and#swapsemantics like those of a Javavolatile. Actually, they may be stronger -- I'd like to just use a load barrier inir_getand a store barrier inir_set, but I don't know how to do that short of using inline assembly.Feedback please!
Closes #3.