-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's implement threads.mutex #12
Comments
@yegor256 Can I do it? |
@levBagryansky sure, but I would name them
This is the most logical way of dealing with locks, I believe |
@yegor256 ok. I thought
But do |
@yegor256 Will we use
? |
@levBagryansky in this case we can only acquire ONE lock, while a proper mutex should allow multiple of them:
The number of locks in the mutex should be a mandatory argument of |
@yegor256 How can we lock the already existing
|
@yegor256 may be we can write
to create a new mutex? |
@levBagryansky our
|
@yegor256 So when in the same time another thread will do |
@levBagryansky yes, of course |
@yegor256 ok thanks |
@yegor256 Must the second |
@levBagryansky must cause and error, of course |
@yegor256 Seems it is impossible to use personal
|
@levBagryansky I don't think it's true. In order to dataize |
@yegor256 It does not dataize
This is the test:
When we run the test it ptints "Acquire" twice that poves it would acqure the mutex twice:
|
@levBagryansky 2 puzzles #33, #34 are still not solved. |
@yegor256 Let's implement
mutex
object. It will havemutex.lock
andmutex.unlock
attributes so only onethread
can own themutex
in a moment.The text was updated successfully, but these errors were encountered: