I have a process where memory is sometimes not updated across threads
in Windows. The description follows :
The process has two threads - an 'engine' thread that runs an event
loop using select, and a user thread that periodically makes requests
to the engine thread. The request is done by writing a byte to a
socket which is in the fd list for select. When the engine thread has
completed the task requested, it signals the user thread by writing a
byte on the write end of a pipe (not a named pipe). The user thread,
which had been blocking on the read end of the pipe, releases the
mutex it holds (to prevent other, possible user threads from
simultaneously entering) and returns when it reads the ack byte.
In short, the user thread
locks a mutex,
prepares a request by setting some variables (private variables of an
object that was allocated by the new operator),
sends a signal byte over a socket,
does a blocking read on a pipe for the ack byte and
releases the mutex.
The engine thread
reads the signal byte from the socket (woken up from select)
processes the request after reading the parameters off the private
resets the private variables and
writes an ack byte on the pipe.
The above is built on Linux (where it uses pthreads) and on Windows
where it uses Windows threads and mutexes.
On Linux, the process is well behaved.
On Windows, when a large number of requests are fired rapidly, once in
a while I see that the parameters set by the user thread are not seen
in the engine thread. What the engine thread sees is the older values,
from its point of view.
I was under the impression that system calls like socket and pipe read/
writes, as well as mutex calls would activate memory barriers.
Is it possible that this is not true on Windows, at least for pipes?
(An older version of the code, where the ack byte is sent over the
same socket, does not exhibit this behaviour).
If it is indeed the pipes, I am considering using Windows
synchronization methods like SetEvent to handle the signalling - is
that considered safe?
On Windows I compile using MSVC 6.0, but I have tried MSVC 2003 as