-1

I have a four member functions that can be called multiple times asynchronously from other piece of code - but since these functions are making use of its class member variables, I need to ensure that until one call execution is not over the second should not start but be in queue.

I have heard of lock guard feature in C++ that make a code block - in my case as automatic lock for a duration for a function :

void DoSomeWork()
{
    std::lock_guard<std::mutex> lg(m); // Lock will be held from here to end of function
--------;
return;
}

Since my four class methods do independent work should I have four mutex one for each lock guard for each member function. Will the async calls made be in some sort of queue if a lock guard is active?

I mean if there are say 10 calls made to that member method at same time - so once 1st call acquires the lock guard the remaining 9 call request will wait until lock is free and take up execution one by one?

Sid S
  • 6,037
  • 2
  • 18
  • 24
Programmer
  • 8,303
  • 23
  • 78
  • 162
  • Did you mean 10 threads making the call at the same time? If so, you should edit your question to specify that multiple threads are involved. – rcgldr Dec 05 '18 at 04:42
  • see this:https://stackoverflow.com/questions/37860811/do-mutexes-guarantee-ordering-of-acquisition – Charlie Dec 05 '18 at 04:59
  • The flow is single thread only except that the multiple callbacks can call asynchronously – Programmer Dec 05 '18 at 06:56

2 Answers2

1

If a mutex is locked, the next request to lock it will block until the the previous thread holding the lock has unlocked it.

Note that attempting to lock a mutex multiple times from a single thread is undefined behavior. Don't do that.

For more information see e.g. this std::mutex reference.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • 1
    The OP states 10 calls made to a function that locks a mutex at the same time, which would seem to imply multiple threads, but it's not clear. – rcgldr Dec 05 '18 at 04:41
  • Thanks - then what is best solution for same to avoid deadlock or undefined behaviour – Programmer Dec 05 '18 at 04:43
  • There is a server code that reads code from a port and calls callbacks to handle asynchronously - the callback functions then will call my functions. So there is no multiple thread in my case – Programmer Dec 05 '18 at 04:47
  • @Programmer As long as you have different threads attempting to lock the mutex, then it should not be a problem (unless you attempt to lock multiple different mutexes, then all threads must attempt to lock them in the same order). And if you attempt to lock a mutex multiple times in a single thread, then either the lock is to coarse *or* to narrow. – Some programmer dude Dec 05 '18 at 04:47
  • @Programmer If you don't have multiple threads, it's all single-threaded, then you can't use mutexes or locks. But then you don't *need* them anyway since you only have a single thread of execution, you simply can't call a function in parallel needing the lock. – Some programmer dude Dec 05 '18 at 04:49
  • The flow is single thread only except that the multiple callbacks can call asynchronously – Programmer Dec 05 '18 at 05:02
  • 1
    @Programmer "Asynchronously" doesn't imply "multi-threaded". Look at node.js, which is asynchronous but still single threaded. Even if your function can be called "asynchronously" (using some kind of event-loop and callbacks) it's still a single thread, and can't be called in parallel. So no need for locks. You need to look at the framework you're using and read its documentation to know if it's using a new thread for its event loop and event callbacks. – Some programmer dude Dec 05 '18 at 05:07
0

Assuming you mean multiple threads issuing locks for the same mutex, based on prior questions, there's no queuing for pthreads or posix synchronization types. Say multiple threads each have a loop that starts with a lock and ends with an unlock, looping right back to the lock request, in which case the same thread can keep getting the lock, and none of the other threads will run (there's a very small chance that a time slice could occur between the unlock and lock, switching context to another thread). Using conditional variables also have an issue with spurious wakeup.

https://en.wikipedia.org/wiki/Spurious_wakeup

Based on testing, Windows native synchronization types, (CreateMutex, CreateSemaphore, WaitForSingleObject, WaitForMultipleObjects) do queue requests, but I haven't found it documented.

Some server applications on some operating systems will install a device driver that runs at kernel level in order to workaround the limitations of synchronization types on those operating systems.

rcgldr
  • 27,407
  • 3
  • 36
  • 61