How to use lock?

Good day!
Trying to use a mutex to lock the thread
std::mutex locker;
locker.lock();
// Here is the threading at the end of which will be called locker.unlock();
locker.lock();

I need to use locks to make sure that the threads finished their work
But when the program falls on the second locker.lock();
How to use locks in this case?
PS the Problem you need to solve it with mutex locks. The example I wrote is very conditional, not to load unnecessary code
June 10th 19 at 14:34

Related questions

More answers about "How to use lock?"
2 answers
June 10th 19 at 14:36
Solution
Will sum up of my suffering with this problem, if anyone face the same problem
In one thread you cannot use a locker.lock() twice in a row, as a protection against deadlocks
We used the following spike:
std::mutex locker;
boost::thread t([&]() {
locker.lock();
});
t.join();
...
locker.lock();
That kind of nonsense? Why? - Zit commented on June 10th 19 at 14:39
why just nonsense?
Just crutch :)
I use a class, which causes several streams, one within another
And I need to wait until all threads will do their work and then move on with the main program
There is a class https request
Code is something like this:
std::string info = "Hello world!";
request->query("https://site.com/", [&]{
 std::cout << info;
});

And in result info for a as a becomes unavailable, because the main thread terminates and destroys all the local variables
Of course you can pass your variables in the function as well, but it is too gemorno since I use a lot of local variables (I for example just one variable written)
So it is easier just to keep the main thread until the callback completes - rigoberto commented on June 10th 19 at 14:42
you need to change the architecture, because it's the crutches some.
And I need to wait until all threads will do their work and then move on with the main program

For this is join streams, shove them into an array and wait until the completion of all. In General, for network requests better to use async and not threads. - Zit commented on June 10th 19 at 14:45
lock is needed to synchronize access to data. If you want to wait until the other threads – use loop through the array of threads and call join on each. - bernhard36 commented on June 10th 19 at 14:48
, I knowingly said that there are several threads, one within another
I know about join, and about the future&async
Just the task is very specific and requires that the implementing class
Here is the rate for sending rate request
And there is quite a complex class is doing
Just in this piece of code I don't really use the appointment class
The point is that these 2-3 places, where do not have to use the class
But the meaning for these 2-3 places to write a separate class when these pieces of code are invoked very rarely, and there is not required neither the speed nor optimized? Pointless, because you can hostility :)
+ I was interested to find out what's wrong with the second lock, which determined the creation of a question on the toaster
PS just in case I will specify that the program is written for personal use, so that you can a bit of dirt in the code to prevent - rigoberto commented on June 10th 19 at 14:51
, joins om will not work
The main argument is that the callback is sent in a separate thread, while the class will complete the necessary actions
In addition, for single request->query may create several nested within other flows. And in this callback may not be called directly from the current thread, since the class can send the request in a queue and then they will be doing another stream which runs done independently
In short, not an option
And at the expense of locking... Why am I unable to apply them in this case? Somewhere it is written "is used for synchronizing data access", doesn't mean that you can't use locks to synchronize threads? Or there are some serious arguments against?
And by the way, I'm not sure, but it seems I still trying just "to synchronize access to data." Give the thread access to the data before it will get the memory optimizer :) - rigoberto commented on June 10th 19 at 14:54
understood, in this case, really not a lot of options.

But is this crutch works? You start the thread that locks the mutex. Immediately after waiting a thread to terminate and then again try to lock the mutex, but in the main thread. And at this point the program hangs, because the mutex is already locked and the main thread will wait for unlock it. How do you release the mutex to other threads?

Not trying in some way to blame or to convince myself wondering how this problem can be solved in other ways. - bernhard36 commented on June 10th 19 at 14:57
again , the problem in the architecture. If you need speed - use the asynchronous library a bunch of them. - Zit commented on June 10th 19 at 15:00
I was there three dots put
It is implied that there will be made unlock
The complete code looks something like this:
std::mutex locker;
boost::thread t([&]() {
locker.lock();
});
t.join();

std::string info = "Hello world!";
request->query("https://site.com/", [&]{
 std::cout << info;
locker.unlock();
});

locker.lock();

The main thread will exist until callback will finish its work. Certainly good need to pass variables to the callback, and not to hold local variables. But in this case ovchinka not worth the candle :) - rigoberto commented on June 10th 19 at 15:03
OK, thanks for your opinion, I heard
Just as I said, in this case this is not asynchronous
There is not time saving
The class has its own methods, how to run faster
As I said, I'm not really on purpose I use this class in this place, so we have to use these crutches
When I use the class in the right place, it makes no sense to keep the main stream, as it sends the request, and then he made him not care. The task of the main thread just call a method - rigoberto commented on June 10th 19 at 15:06
I mean, what's more hardware on the number of threads is not always efficient because it will be much time spent on context switching. If I had to use threads, then it may be worth it to make that request->query-returned future, to add them to the array and wait for the completion of all requests.

In General, without knowledge of the specific tasks is difficult to advise anything. - Zit commented on June 10th 19 at 15:09
June 10th 19 at 14:38
An example I wrote very conventional,

Too conditional, do not understand what your problem is.
A primitive example of use.
ru.cppreference.com/w/cpp/thread/mutex
Can also use
en.cppreference.com/w/cpp/thread/lock_guard
to automatically lock/unlock the current scope.
The bottom line is that if I do this:
locker.lock();
locker.lock();

it throws an exception:
5a35354b115fa237550029.png
According to the logic because in this case, the first lock the mutex should be locked and the second lock, the program should wait until it will be unlocked again to lock it
I'm not confused?
In fact, if two consecutive call lock, then the program should hang, but should not fall out an exception? Or is it some kind of protection system from deadlock? If so, how to circumvent it? - Zit commented on June 10th 19 at 14:41
,
No. From one thread in a row lock might not be called.
https://rsdn.org/forum/cpp/6545265.hot
You're trying to do something strange. - rigoberto commented on June 10th 19 at 14:44
,
According to the logic because in this case, the first lock the mutex should be locked and the second lock, the program should wait until it will be unlocked again to lock it
I'm not confused?
In fact, if two consecutive call lock, then the program should hang, but should not fall out an exception? Or is it some kind of protection system from deadlock? If so, how to circumvent it?

It's all described in the standard
If lock is called by a thread that already owns the mutex, the behavior is undefined: for example, the program may deadlock. An implementation that can detect the invalid usage is encouraged to throw a std::system_error with error condition resource_deadlock_would_occur instead of deadlocking.
- Zit commented on June 10th 19 at 14:47
, Yes
So used the crutch above - bernhard36 commented on June 10th 19 at 14:50
if I understand correctly, when you call to lock a specific mutex, all other calls to lock the mutex from other threads will wait for his release.

What do you want (twice cause the lock to one yet) is meaningless. Because you have locked the mutex, what's the point to block it again.

You don't seem to understand why this is necessary, so I suggest you to read the theory on multi-threaded programming. - rigoberto commented on June 10th 19 at 14:53
I understand what I want to do
After all, as you have probably understood, it is understood that between the two lock AMI happens unlock from called flow
This is just for example I wrote two times in a row lock, to demonstrate the exception - rigoberto commented on June 10th 19 at 14:56

Find more questions by tags C++