Re: Smarter CSingleLock?
On Thu, 10 Apr 2008 20:15:39 GMT, Your Name <none@none.none> wrote:
Yes, exactly. The writer thread (there is only one writer) writes data,
and this may cause a variable-sized memory allocation. Once the allocation
is finished, all pointers are updated, and then the count is incremented.
No reader thread will attempt to read the new sample until the count is
incremented. The count is just a DWORD. I've always single considered
DWORDs safe, with no need for synchronization. Are you saying that this is
a bad assumption?
They are "safe" in the sense that reads and writes are atomic; that is,
they aren't subject to "word tearing", which can happen when it takes more
than one memory operation to access a piece of data, resulting in a value
that is a mish-mash of different writes. Of course, read/modify/write
operations such as incrementing are not thread-safe and must be
synchronized in some way. How are you keeping the readers at bay while
you're incrementing, and how do you release them?
P.S. Whenever CSingleLock comes up, I always like to ask if there's a
problem with the following:
// i is a variable we must synchronize access to.
CSingleLock lk(cs);
++i;
The main problem I see is that the bInitialLock parameter defaults to
FALSE. Kind of an odd choice for a default parameter! :)
You got it! The wrongness of this default is matched only by how surprising
it is, which is why I mention it.
--
Doug Harrison
Visual C++ MVP