Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Why Boost UpgradeLockable Concept (http://www.boost.org/doc/libs/1_57_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.upgrade_lockable) have unlock_and_lock_* and unlock_upgrade_and_lock_* but don't have unlock_shared_and_lock_? It have try_unlock_shared_and_lock_ but only when BOOST_THREAD_PROVIDES_SHARED_MUTEX_UPWARDS_CONVERSIONS is available and I don't want to "try". There's some restriction about doing such operations?
The entire purpose of an upgradeable lock is that you can atomically upgrade it to an exclusive lock. If you could do that with a shared lock, what purpose would upgradeable locks serve?
If you had an unlock_shared_and_lock, what would happen if two threads called it at the same time? Under what circumstances would it be safe to call?
If you might need to atomically upgrade a lock, you need to acquire an upgradeable lock. That's their entire purpose.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 months ago.
Improve this question
I have a thread that must wait until a condition is true or until a timer runs out and I was thinking which would be the best way to solve it, I though about condition variables but I am not sure if is the best method since I could have race condition, I would be happy to hear your suggestion.
Thank you.
A simple way is to have a locked mutex that your thread can wait for. Your timer can then unlock the mutex when you want the thread to continue.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
All in title. Since coroutine just need a sort of EIP memory, and thread provides that, is it possible to do it? That's way to have a highly portable coroutine library.
You can implement coroutines / generators based on threads or even fibers. But they would be less performant compared to implementations like msvc or gcc provide.
I implemented coroutines that way (no threads, but fibers) in delphi. You need to estimate how much stack-memory do you need, you need to create those threads (which is heavy...).
So you should avoid that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am beginner in concurrent programming on C++. I read about std::atomic_flag and I don't understand where this atomic_flag can be useful. Maybe someone can explain me for which tasks atomic_flag can be useful
cppreference.com has a usage example. It also contains the following explanatory note:
Unlike all specializations of std::atomic, it is guaranteed to be lock-free.
In other words: you’d use it the same way you would use std::atomic<bool> but with the added guarantee of lock-freeness (though on most systems std::atomic<bool> will also be lock-free, i.e. std::atomic<bool>::is_always_lock_free will be true).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have two threads sharing a variable, but neither of them writes to that variable. I do understand that when two threads are dynamically reading or writing the variable, you do need a mutex. However, since, I am only reading the shared variable from either threads, do I still need to use a mutex?
P.S. Mine is a C++ program and I am using std::mutex.
If the variable is guaranteed not to be changed, then the reads don't need a mutex.
But if:
It's possible that the variable is written (by any thread) at the same time your threads are trying to read it
And, reads / writes are not atomic
Then you do need to synchronize.
As long as they are only reading from the variable, and the variable can be written/read with one store/read word operation then you don't.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I would like to know if Weak Pointers can be used against/instead of Mutex/Critical Sections for synchronization issues.
If the only synchronisation issue you've got is ensuring the object's still around when you'd like to access it, then getting a shared_ptr from a weak_ptr will ensure its lifetime is extended. It's only sufficient for very narrow scenarios though, for example - if a shared_ptr is stored in a container somewhere, and may be erased at any time but is otherwise unused, while your code with the weak_ptr may want to actually access or modify the data content of the object.
If you also need to protect against concurrent accesses during updates to the data in the object, then you need more than that shared_ptr....