MSVC memory barrier issue.

Marc Lehmann schmorp at schmorp.de
Sat Jan 4 10:45:47 CET 2014


On Sat, Jan 04, 2014 at 01:35:44AM -0800, Nicolas Noble <nicolas at grumpycoder.net> 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
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list