On non-POSIX systems, it seems that interprocess_condition is emulated using a loop, as you describe in your in question. And interprocess_semaphore is emulated with a mutex and an interprocess_condition so wait()-ing ends up in the same loop.
Up vote 0 down vote favorite 1 share g+ share fb share tw.
I'm writing a multithreaded app. I was using the boost::interprocess classes (version 1.36.0) Essentially, I have worker threads that need to be notified when work is available for them to do. I tried both the "semaphore" and "condition" approaches.
In both cases, the CSwitch (context switch) for the worker threads seemed very high, like 600 switches per second. I had a gander at the code and it seems like it just checks a flag (atomically using a mutex) and then yields the timeslice before trying again next time. I was expecting the code to use WaitForSingleObject or something.
Ironically, this was exactly how I was doing it before deciding to do it "properly" and use Boost! (i.e. Using a mutex to check the status of a flag regularly).
The only difference was, in my approach I was sleeping like 50ms between checks so I didn't have the high CSwitch problem (and yes it's fine for me that work won't start for up to 50ms). Several questions: Does this "high" CSwitch value matter? Would this occur if the boost library was using CRITICAL_SECTIONS instead of semaphores (I don't care about inter-process syncing - all threads are in same process)?
Would this occur if boost was using WaitForSingleObject? Is there another approach in the Boost libs that uses the aforementioned Win32 wait methods (WaitForXXX) which I assume won't suffer from this CSwitch issue. Update: Here is a pseudo code sample.
I can't add the real code because it would be a bit complex. But this is pretty much what I'm doing. This just starts a thread to do a one-off asynchronous activity.
NOTE: These are just illustrations! There is loads missing from this sample, e.g. If you call injectWork() before the thread has hit the "wait" it just won't work. I just wanted to illustrate my use of boost.
The usage is something like: int main(int argc, char** args) { MyWorkerThread thread; thread.startThread(); ... thread. InjectWork("hello world"); } Here is the example using boost. Class MyWorkerThread { public: /// Do work asynchronously void injectWork(string blah) { this->blah = blah; // Notify semaphore this->semaphore->post(); } void startThread() { // Start the thread (Pseudo code) CreateThread(threadHelper, this, ...); } private: static void threadHelper(void* param) { ((MyWorkerThread*)param)->thread(); } /// The thread method void thread() { // Wait for semaphore to be invoked semaphore->wait(); cout blah = blah; this->workReady = true; section.unlock(); } void startThread() { // Start the thread (Pseudo code) CreateThread(threadHelper, this, ...); } private: /// Uses Win32 CriticalSection class MyCriticalSection { MyCriticalSection(); void lock(); void unlock(); }; MyCriticalSection section; static void threadHelper(void* param) { ((MyWorkerThread*)param)->thread(); } /// The thread method void thread() { while (true) { bool myWorkReady = false; string myBlah; // See if work set section.lock(); if (this->workReady) { myWorkReady = true; myBlah = this->blah; } section.unlock(); if (myWorkReady) { cout.
– Éric Malenfant Oct 13 '09 at 17:35 Yup - sample code added. – John Oct 14 '09 at 10:34.
On non-POSIX systems, it seems that interprocess_condition is emulated using a loop, as you describe in your in question. And interprocess_semaphore is emulated with a mutex and an interprocess_condition, so wait()-ing ends up in the same loop. Since you mention that you don't need the interprocess synchronization, you should look at Boost.
Thread, which offers a portable implementation of condition variables. Amusingly, it seems that it is implemented on Windows in the "classical" way, using a... Semaphore.
That's great - I'll try this out. – John Oct 20 '09 at 9:07.
If you do not mind a Windows specific (newer versions on windows), check the link for light weight condition variables CONDITION_VARIABLE (like critical sections).
Thanks for suggestion. Unfortunately I need to support XP. Plus, I'm trying to keep the codebase portable wherever possible.
Thanks, though. – John Oct 14 '09 at 10:34.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.