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?
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".
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.
Reply With Quote
They simply do what needs to be done for that particular OS/architecture.
Bookmarks