Hi, Although Block Pointer is now thread safe it could use some optimization. To do so it'll need some special operations on mutexes such as move and merge. The operations need to be atomic as well. I was wondering if this was already attempted. Thanks, -Phil
AMDG On 05/17/2011 04:51 PM, Phil Bouchard wrote:
Although Block Pointer is now thread safe it could use some optimization. To do so it'll need some special operations on mutexes such as move and merge. The operations need to be atomic as well.
What do you mean by merge? What semantics do you expect from move? In Christ, Steven Watanabe
On 5/17/2011 9:11 PM, Steven Watanabe wrote:
What do you mean by merge?
So you have 2 sets that could be locked by thread 1 and 2. Now thread 1 wants to take ownership of the 2 sets so it'll need to lock mutex 1 and 2.
What semantics do you expect from move?
Sorry I needed to disambiguate what is needed but a move won't be necessary. -Phil
Phil Bouchard wrote:
On 5/17/2011 9:11 PM, Steven Watanabe wrote:
What do you mean by merge?
So you have 2 sets that could be locked by thread 1 and 2. Now thread 1 wants to take ownership of the 2 sets so it'll need to lock mutex 1 and 2.
This is not supported directly by the underlying platforms and will require the need of synchronization between the threads which will result in a expensive operation that you could implement yourself on top of the existing API. Could you explain in which case do you need to use this merge operation? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/mutex-move-merge-tp3531125p3531638.html Sent from the Boost - Dev mailing list archive at Nabble.com.
On 5/17/2011 10:43 PM, Vicente Botet wrote:
This is not supported directly by the underlying platforms and will require the need of synchronization between the threads which will result in a expensive operation that you could implement yourself on top of the existing API.
Could you explain in which case do you need to use this merge operation?
Sorry for the confusion but it turns out I won't need this operation either. -Phil
On 5/17/2011 10:56 PM, Phil Bouchard wrote:
Sorry for the confusion but it turns out I won't need this operation either.
The bottom line is I would need a ~mutex() that discards errors and an atomic way of performing the following consecutive locks: template <typename V> block_ptr & operator = (block_ptr<V> const & p) { mutex::scoped_lock scoped_lock1(ps_->redir()->mutex_); mutex::scoped_lock scoped_lock2(p.ps_->redir()->mutex_); ... } But the latter would require locking a global mutex once again so there's no real gain of optimizing it because it already locks a global mutex. -Phil
Phil Bouchard <philippe@fornux.com> writes:
On 5/17/2011 10:56 PM, Phil Bouchard wrote:
Sorry for the confusion but it turns out I won't need this operation either.
The bottom line is I would need a ~mutex() that discards errors and an atomic way of performing the following consecutive locks:
template <typename V> block_ptr & operator = (block_ptr<V> const & p) { mutex::scoped_lock scoped_lock1(ps_->redir()->mutex_); mutex::scoped_lock scoped_lock2(p.ps_->redir()->mutex_);
... }
Is boost::lock() any help here? It will lock multiple mutexes without deadlock due to ordering concerns. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On 05/18/2011 12:17 AM, Phil Bouchard wrote:
The bottom line is I would need a ~mutex() that discards errors and an atomic way of performing the following consecutive locks:
template <typename V> block_ptr & operator = (block_ptr<V> const & p) { mutex::scoped_lock scoped_lock1(ps_->redir()->mutex_); mutex::scoped_lock scoped_lock2(p.ps_->redir()->mutex_);
... }
Combining the locking of multiple mutexes requires defining an order in which they should always be acquired so as to define a lock hierarchy. Using the address of the mutex in question for that ordering should work.
On 5/18/2011 8:45 AM, Mathias Gaunard wrote:
Combining the locking of multiple mutexes requires defining an order in which they should always be acquired so as to define a lock hierarchy.
Using the address of the mutex in question for that ordering should work.
That's unfortunate because it'll uglify the code. A more important problem is that "ps_->redir()->mutex_" and "p.ps_->redir()->mutex_" need to be called in a lock mode right before. For that I need to lock a global mutex, which I was trying not to do. -Phil
Phil Bouchard <philippe@fornux.com> writes:
On 5/18/2011 8:45 AM, Mathias Gaunard wrote:
Combining the locking of multiple mutexes requires defining an order in which they should always be acquired so as to define a lock hierarchy.
Using the address of the mutex in question for that ordering should work.
That's unfortunate because it'll uglify the code. A more important problem is that "ps_->redir()->mutex_" and "p.ps_->redir()->mutex_" need to be called in a lock mode right before. For that I need to lock a global mutex, which I was trying not to do.
Using boost::lock() you don't have to worry about defining an ordering; boost::lock() will take care of it for you. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On 5/18/2011 9:48 AM, Anthony Williams wrote:
Using boost::lock() you don't have to worry about defining an ordering; boost::lock() will take care of it for you.
That's great but I need to forget about this strategy since I'll need a global mutex to lock the redir() function calls; i.e. it'll need to lock a global mutex in order to lock 2 other mutexes. I don't think this is worth it. -Phil
On 5/18/2011 3:44 PM, Phil Bouchard wrote:
That's great but I need to forget about this strategy since I'll need a global mutex to lock the redir() function calls; i.e. it'll need to lock a global mutex in order to lock 2 other mutexes. I don't think this is worth it.
Besides I need to disregards errors returned by ~mutex(). Since we can't overload destructors, the whole class will need to be rewritten. -Phil
On 5/18/2011 3:49 PM, Phil Bouchard wrote:
Besides I need to disregards errors returned by ~mutex(). Since we can't overload destructors, the whole class will need to be rewritten.
There should be an option or a macro that makes it dismiss errors. Mutexes that are still locked should be okay to destroyed. -Phil
On 5/18/2011 4:30 PM, Phil Bouchard wrote:
There should be an option or a macro that makes it dismiss errors. Mutexes that are still locked should be okay to destroyed.
... "should be okay to destroy". Locks protect something and if you destroy that something then the lock dies with it. -Phil
participants (5)
-
Anthony Williams -
Mathias Gaunard -
Phil Bouchard -
Steven Watanabe -
Vicente Botet