Does it make sense - mutex locks twice ?
-
Hi all I need to clarify a point with the usage of mutex locking . mutexlock(&mutexobj); Function1(socket &lnk); mutexunlock(&mutexobj); In Function1() { mutexlock(&mutexobj); globalvar1= globalvar2; mutexunlock(&mutexobj); } My questions : -> Is it right/necessary to mutex lock inside Function1()? I understand a global lock/unlock surrounding the call to Function1() will ensure that the whole code / critical resources are thread safe . I find such occurance of such locking/unlocking in many areas of the code I am working with . Is it not a problem ? .
redindian
-
Hi all I need to clarify a point with the usage of mutex locking . mutexlock(&mutexobj); Function1(socket &lnk); mutexunlock(&mutexobj); In Function1() { mutexlock(&mutexobj); globalvar1= globalvar2; mutexunlock(&mutexobj); } My questions : -> Is it right/necessary to mutex lock inside Function1()? I understand a global lock/unlock surrounding the call to Function1() will ensure that the whole code / critical resources are thread safe . I find such occurance of such locking/unlocking in many areas of the code I am working with . Is it not a problem ? .
redindian
You can re-enter the same mutex twice from the same thread: as you are owning it, you won't block when you try to lock it from the same thread. This prevents deadlock situation (if it you block, then re-entering it would cause a deadlock).
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++ -
Hi all I need to clarify a point with the usage of mutex locking . mutexlock(&mutexobj); Function1(socket &lnk); mutexunlock(&mutexobj); In Function1() { mutexlock(&mutexobj); globalvar1= globalvar2; mutexunlock(&mutexobj); } My questions : -> Is it right/necessary to mutex lock inside Function1()? I understand a global lock/unlock surrounding the call to Function1() will ensure that the whole code / critical resources are thread safe . I find such occurance of such locking/unlocking in many areas of the code I am working with . Is it not a problem ? .
redindian
In the case of Mutex, Multiple Lock will not be a problem, but Mutiple unlock creates some problem. The first mutexunlock ( I guess mutexunlock is internally calling
ReleaseMutex()) will release the mutex and so the rest of the code will not be having any effect of the mutex.nave [OpenedFileFinder]
-
You can re-enter the same mutex twice from the same thread: as you are owning it, you won't block when you try to lock it from the same thread. This prevents deadlock situation (if it you block, then re-entering it would cause a deadlock).
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++ -
Thanks . But what I am curious about is - why should there be a lock/unlock inside Function1() when the whole function call is already locked ?.
redindian
In that particular case it doesn't make any sense. But sometimes, when you have a function with multiple 'paths' and some of them call Function1(), then you would like to still lock the full function. But I agree, it is a bit messy...
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++ -
In the case of Mutex, Multiple Lock will not be a problem, but Mutiple unlock creates some problem. The first mutexunlock ( I guess mutexunlock is internally calling
ReleaseMutex()) will release the mutex and so the rest of the code will not be having any effect of the mutex.nave [OpenedFileFinder]
Naveen wrote:
The first mutexunlock ( I guess mutexunlock is internally calling ReleaseMutex()) will release the mutex
No, this is not correct. From MSDN[^]: After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call ReleaseMutex once for each time that the mutex satisfied the conditions of a wait function.
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++ -
Naveen wrote:
The first mutexunlock ( I guess mutexunlock is internally calling ReleaseMutex()) will release the mutex
No, this is not correct. From MSDN[^]: After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call ReleaseMutex once for each time that the mutex satisfied the conditions of a wait function.
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++Ho ho.. :doh: I didn’t know that. Thanks for correcting :rose:
nave [OpenedFileFinder]
-
Naveen wrote:
The first mutexunlock ( I guess mutexunlock is internally calling ReleaseMutex()) will release the mutex
No, this is not correct. From MSDN[^]: After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call ReleaseMutex once for each time that the mutex satisfied the conditions of a wait function.
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++I think its specifically for wait functions called inside a thread . But the code I am listing does not contain any wait functions . There is a second lock/unlock when there is an access to a global variable . Cedric I think Naveen's point that the first call to mutexunlock will unlock the mutex object and the rest of the call to Function1() will not be threadsafe . What do you say ? I am taking an important decision to affect many critical functions which have these occurances..
redindian
-
I think its specifically for wait functions called inside a thread . But the code I am listing does not contain any wait functions . There is a second lock/unlock when there is an access to a global variable . Cedric I think Naveen's point that the first call to mutexunlock will unlock the mutex object and the rest of the call to Function1() will not be threadsafe . What do you say ? I am taking an important decision to affect many critical functions which have these occurances..
redindian
Read the link I provided: there's no such thing as lockmutex and unlock mutex in the Win32 API but it is a WaitForSingleObject and a ReleaseMutex instead. The wait function will have the same effect as a lockmutex when the mutex becomes available. I don't know how you implemented the lock and unlockmutex functions but they should normally follow those rules.
Cédric Moonen Software developer
Charting control [v1.4] OpenGL game tutorial in C++