Writing in one, reading from another

Hi all,

what's the (realistic) worst case scenario that could happen if I read (iterate over equal_range) from a std::multimap in one thread while writing (inserting a new element) in another?

I have an application which will only very rarely write (few dozen times in the first seconds, maybe once every few minutes thereafter), but often read (every couple milliseconds), and I really don't want to have to check a mutex every millisecond for those rare writes.

My understanding of red-black trees (which I believe std::multimaps are) would lead me to believe that nothing horrible could happen, but then again my understanding of red-black trees is nowhere near perfect...

Any other ideas for avoiding a mutex? Or should I just mutex it and get it over with?

Thanks for the feedback!
Zen

Get it over with by doing it right.

The fast-path for acquiring a CRITICAL_SECTION is pretty darn fast. Since you rarely write, readers will take the fast-path most of the time.

gg

What the hell is the fast-path of a criticalsection?

If there are no other threads trying to acquire the CS, then EnterCriticalSection can acquire the CS without making a kernel call. This is the "fast-path".

Otherwise, the thread has to make a kernel call in order to "block" until it can acquire the CS. This is the "slow-path".

InitializeCriticalSectionAndSpinCount() is a similar optimization in that it tries to avoid the kernel call.

gg

If it doesnt need a kernel call, how does EnterCriticalSection make sure that function itself is thread safe?

I mean you could think EnterCriticalSection needs a critical section for itself.. to prevent two threads from going into the critical section at the same time.. lol

This is where the synchronization primitives provide by your OS or threading library "take care of business" :) They simply do what needs to be done for that particular OS/architecture.

Windows OS's run on x86, x64, IA64, MIPS, SHx, ARM, and PowerPC. What "needs to be done" can vary from one platform to the next.

gg