Printable View
Hi,
I want to understand synchronization objects in MFC in detail.
if anybody know about any good book / tutorial, please send me the link for the same.
I want to understand Mutex / Semaphores / Events / Critical Section in detail....How to use implement and use in practical examples.
Regards,
Mbatra
There is also an article in CP: http://www.codeproject.com/Articles/...on-Objects-wit
Not MFC related, but covers synchronisation using c++ and WIN32 by the celebrated author Jeffrey Richter.
http://www.amazon.co.uk/Windows-Via-...3970076&sr=1-1
I never used MFC sync objects though I did a lot of multithreading in MFC. The pure Win32 API way always seemed concise enough to let me get rid of additional class dependencies.
The point about the MFC objects is to allow RAII approach to synchronsiation.Quote:
Originally Posted by Igor Vartanov
initiate the sync by creating an object, and release the sync upon destruction.
Without something like this in place, your code won't be exception safe... As in... thrown exceptions may cause some sync objects to remain locked even though the portion of code they were protecting has gone out of scope. this could lead to hard to reproduce/solve bugs.
You don't have to use the MFC objects ofc, but wrapping your synchronisation in classes is a good idea.
Explaining what each of these does is simple enough and there are tons of explanations out there.Quote:
Originally Posted by Mbatra
There is no way to give practical examples other than very specific examples which you shouldn't just copy/paste into some bit of code of yourself and expect this to work properly. It takes a lot of practice and testing to get this right.
Fact remains that using synchronisation properly is extremely difficult.
Most devs tend to adopt a wide approach to things and use broad locking. This works, but it means you aren't getting the best performance or throughput.
But it's better than the other way around where not having enough means your program will fail somewhere down the line (usually with your most important client at the worst possible moment in time, and you can't possibly reproduce this on your own test machines).
And I never said I did something opposite to RAII. :) Operating with pure WinAPI primitives just makes me be less nervous. :)Quote:
Originally Posted by OReubens
Hi,
Is "C++ concurrency in Action" by "ANTHONY WILLIAMS" a good book to learn about practical multithreading and synchronization.?
Regards,
Mbatra
This book only covers concurrency as part of the new c++11 standard. It doesn't cover MFC or Windows specific concurrency.Quote:
Originally Posted by Mbatra
In fact, there's no such a thing as "synchronization objects in MFC". There are only Windows synchronization kernel objects wrapped in a few thin MFC classes. So, to understand Windows synchronization in detail I would recommend to forget about MFC for some time and go with Richter's book already mentioned here.Quote:
Originally Posted by Mbatra
BTW, there's some flaw in your plan. Not only critical section, mutex, semaphore and event can be used for synchronization purpose, but any kernel object able to signal to synchronization API can do for you.
that "but any object able to signal" is wrong or at least incomplete.Quote:
Originally Posted by Igor Vartanov
A critical section does not signal. In fact it can't even be part of a WaitForSingleObject()/WaitForMultipleObjects() or similar type call. But it can be used for synchronisation.
That's why even though critical sections and unnamed mutexes seem to "do" exactly the same thing, they aren't interchangable.
a critical section is a lightweight lock that offers basic locking (but without signalling) wheras an unnamed mutex offers basic locking WITH signalling.
Not all OSes/platforms offer this lightweight variant and instead expect you to use an unnamed mutex anyway. And there's no problem here, other than that the needs to signal make a mutex a bit more complex and slower performing.
Other than that, synchronisation can also be achieved by means other than kernel objects. The Interlocked...() family of functions may be all you need to guarantee synchronisation across threads. And you can even make more complex synchronsiation primitives based on these. You can even make your own signalling primitives based on these, but the crucial difference is that the signalling code will be user mode instead of kernel mode and this will have consequences somewhere (which can be either good or bad depending on the needs of the program).
The "weirdest" of the non-signalling primitives are the so called "lock free" algorithms.
And other than that, there are ways to guarantee synchronisation without even using any of the above, although it'll typically result in a significant difference in performance (lock/unlock speed)compared to the kernel objects, but they'll have advantages of their own that the kernel objects can't provide.
Synchronization API is not limited to WaitForXxxObjects only. And yes, critical section does signal to RtlpWaitForCriticalSection which EnterCriticalSection internally does, and which ultimately goes down to ZwWaitForSingleObject call. It in fact partially operates on event object opaquely used by CS API. :)Quote:
Originally Posted by OReubens