On 11/30/2012 6:24 PM, NuSkooler wrote:
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.
Not exactly right.
WaitForSingleObject() and friends return as follows:
WAIT_OBJECT_0 if the first condition was satisfied normally
For a mutex, this implies that the mutex was taken after
being released normally by some other thread (or no thread
if it was just allocated), or the waiting thread already
holds the mutex and the recursion count was incremented.
WAIT_ABANDONED_0 if the first condition was a valid Mutex handle
AND the mutex was held by another thread AND that other
thread ended without manually releasing the mutex first.
The mutex is still obtained be the waiting thread, this
differs from WAIT_OBJECT_0 only by informing the waiting
thread that the previous Mutex owner didn't release it
before dying.
WAIT_FAILED with GetLastError()==ERROR_INVALID_HANDLE if any of the
condition handles were invalid or closed before entering
the wait. (Once in a wait, the wait code in the kernel
will hold an internal reference to each condition object,
making it immune to handle closure, the handle checking
and reference counting is a single atomic operation).
WAIT_TIMEOUT if a non-infinite timeout was specified as an argument
to the Wait function, and that timeout was reached before
any other condition was satisfied. In particular a
timeout limit of 0.0 microseconds will check the condition
and return WAIT_TIMEOUT if no other return value is
instantly possible.
WAIT_IO_COMPLETION if the Wait function was passed an argument of
bAlertable != FALSE or a flag mask that included the
MWMO_ALERTABLE bit AND an APC (similar to a UNIX signal
handler) was executed in the waiting thread before the
wait completed.
WAIT_OBJECT_0 and WAIT_ABANDONED_0 are just the first in two parallel
ranges of up to 64 return values indicating which of
the conditions passed to WaitForMultipleXxx() was
satisfied first. For instance if the conditions were
"MutexFoo OR STDIN OR Message ready", then
WAIT_XXXX_0 + 0 means you now hold MutexFoo,
WAIT_XXXX_0 + 1 means data available on STDIN,
WAIT_XXXX_0 + 2 means PeekMessage() needs to be called
in a loop until it returns FALSE.
All the various "Wait" functions are really wrappers around the Syscall
NtWaitForMultipleObjects which is a wrapper around the kernel mode
function KeWaitForMultipleObjects. The different public functions
only vary in how the parameters to the underlying call are set.
So unless you pass one of the special "Complete in other situations"
arguments or passed in a completely bogus handle, a returning wait
function always means you now hold the Mutex, Semaphore etc. you
asked for, and there is no need to check the return value in release
builds.
Debug builds may want to assert that WAIT_FAILED was not returned, but
good debuggers have an option to always break when an invalid handle
is passed to any system function, this is done by setting a per process
"global" flag which the SysCall code checks before returning
WAIT_FAILED. So you don't need to code that assert manually (and get
it wrong some of the time).
If you don't need to synchronize with other processes AND you don't
need to be woken up when a mutex-holding thread ends while holding
the mutex, it is more efficient to use the CRITICAL_SECTION object
which is optimized for this usage and has been heavily tuned by
Microsoft core developers so it can be taken in a handful of CPU
cycles unless there is actually something to wait for, whereas
WaitForXxx() will go through hundreds or even thousands of instructions
to do user/kernel mode transitions, check parameters etc.
Interestingly, the CRITICAL_SECTION functions cannot return failure,
although the InitializeCriticalSection() function may throw an
exception in rare circumstances.
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
<mailto:noloa...@gmail.com>> wrote:
On Thu, Nov 29, 2012 at 9:57 AM, Staneva, Yana <ysten...@micros.com
<mailto: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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
