On Sat, Jan 04, 2014 at 01:35:44AM -0800, Nicolas Noble <[email protected]> wrote: > Basically, if you refer to the MSDN, (from this article, more precisely: > http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.90).aspx ) the > _ReadWriteBarrier() intrinsic is now only a compiler intrinsic that only
This should be fine, as the required variables are marked as volatile, and according to this: http://msdn.microsoft.com/en-us/library/12a04hfd%28v=vs.90%29.aspx volatile variables, as a compiler extension, already act as memory barries (and the article explicitly says using it to implement locks in multithreaded apps etc. is ok). > For more details, if needed, I can provide a fully-featured reproduction > case tomorrow - it's 1:30am right now, and I'm only glad I finally found > this one - but here is some pseudo-code that exacerbates and demonstrates > the problem: This would then either be a compiler bug (as the required vars are volatile), or another bug unrelated to memory barriers (e.g. in libev itself, which would be scary, but looks very unlikely at this point). > Another workaround I first found, that confirms the problem, is that I've > changed pipe_write_wanted to always be 1. Same exact code using the old > barrier code, just writing 1 in pipe_write_wanted instead of 0, in order to > force writing into the pipe. That should demonstrate that pipe_write_wanted > is getting desynchronised between the thread that runs evpipe_write and the > main thread that runs ev_run. Which it shouldn't be, as pipe_write_wanted is also marked as volatile, and gets acquire/release semantics. > Let me know if you have further questions or concerns about this, or if > you really want a short reproduction code to demonstrate this - right now > my code is a full-blown application that wouldn't be very easy to use as a > test case. I don't really mind making libev slower for visual C to work around bugs in the compiler, so I'll gladly just apply your patch, whether its needed in a future version of the compiler or not :) Thanks for finding this bug, and providing a workaround. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [email protected] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
