I think responses like this would be much more helpful without the FUD. WaitForSingleObject() and WaitForMultipleObjects() return *WAIT_ABANDONED *if the mutex has been closed. WAIT_OBJECT_0 would only be expected if you didn't read the documentation. I suggest you both do so before utilizing these functions.
Also, I'm not aware of any such race conditions in Boost. Perhaps in very old versions, but the threading library is solid. Again, you probably want to read the documentation before utilizing. On Fri, Nov 30, 2012 at 9:03 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Thu, Nov 29, 2012 at 9:57 AM, Staneva, Yana <ysten...@micros.com> > wrote: > > #define MUTEX_TYPE HANDLE > > > > #define MUTEX_SETUP(x) (x) = CreateMutex( NULL, FALSE, NULL ) > > > > #define MUTEX_CLEANUP(x) CloseHandle(x) > > > > #define MUTEX_LOCK(x) WaitForSingleObject( (x), INFINITE ) > > > > #define MUTEX_UNLOCK(x) ReleaseMutex(x) > > > > #define THREAD_ID GetCurrentThreadId() > Don't use these macros. On Windows, you must check return values > (that's non-negotiable). WaitForSingleObject is especially egregious > because it could lead to corruption. For example, if you accidentally > close the Mutex, WaitForSingleObject will return ERROR_INVALID_HANDLE > rather than the expected WAIT_OBJECT_0. > > Boost is another offender. It ignores return values and suffer races > in its threading gear. Be very careful if you are using that library > on Windows. > > I can't explain all the defective code circulating. Folks must all be > copy/paste'ing the same junky code. > > Jeff > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
