Pitfalls on using MFC Synchronization Objects

I have employed MFC Synchronization objects in my projects without any issu开发者_开发技巧es. But recently I came across an article, which explains MFC synchronization is completely wrong. I'm not sure which version of MFC he's talking about but I seriously believe that MFC has matured in the recent versions. I'm using MFC library which comes along with Visual Studio 2008 Installation. Is it safe to use MFC libraries of this version especially for synchronization?

---

On mutex timeouts, there is a school of design for concurrent software that says you should not use timeouts for normal operation. Your design would then involve mutexes or other locks that do not time out ever, and timeout is effectively a mechanism for dealing with deadlocks: you try to design your system not to exhibit deadlocks, but in case they do happen, you would rather have it fail more or less gracefully, than stay dealocked forever.

If you use your locks in this way, it may well not matter much why trying to acquire a mutex failed.

On the other hand it does seem maybe not fundamentally broken, but at least somewhat deficient that this information is lost for no good reason and there are better frameworks out there that provide OO wrappers for mutexes, so regardless of this avoiding MFC in this case seems like a good idea.

---

The author's assertions are not appropriate for every condition, but for specific set of conditions. Lock returns BOOL, and you mostly would not care if it failed because of some reason. Most of the time you would call to get the lock or wait. In other cases, FALSE would mean failure. And if you need to check timeout, you can use native API (which is rare).

Recursive CSingleLock is absurd. You don't use same object to relock. You can safely use multipe CSinlgeLock objects to gain recursive access.

CEvent, CMutex and other named-object classes can be used accross process. I have used it!

I don't use Semaphores. May be some other can comment.