Re: Smarter CSingleLock?
On Thu, 10 Apr 2008 07:25:20 GMT, Your Name <none@none.none> wrote:
Hi all,
I have a multi-threaded application with several threads reading and
writing to a global data structure. A thread might read a single value, or
it might read a consecutive range of values. A thread always writes only a
single value, and it is always written at the end. Once data is written,
it is not modified. So, reading and writing are inherently safe with
regards to each other.
You would still need to use memory barrier instructions on multiprocessor
systems with weakly ordered memory subsystems, e.g. Itanium. Also, I'm
concerned about how you define "end"; presumably, it's a pointer or a
count, the writer updates it, and the reader reads it, and if so, you have
concurrent access you will need to synchronize.
The only real danger is the clear operation. Memory allocation is managed
in a complex way, so the clear function usually has a lot of work to do. A
read or a write during this cleanup could cause an access violation. The
way I've been handling this is to put a CSingleLock using a
CCriticalSection at the entry to all the read functions, the write
function, and the clear function.
But it dawns on me now that this is overkill. Handling it this way causes
all reads and writes to be mutually exclusive. So is there an alternative
to CSingleLock that would let me control exactly who has to wait for who?
For example, read has to wait for clear, write has to wait for clear, clear
has to wait for both read and write, but read does not have to wait for
write, and vise versa.
Unless it's an identified bottleneck, I wouldn't worry about it, but in
case it is, you might find the following interesting:
Slim Reader/Writer (SRW) Locks
http://msdn2.microsoft.com/en-us/library/aa904937(VS.85).aspx
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;
--
Doug Harrison
Visual C++ MVP