Boost logo

Boost :

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-04-28 19:38:55

>Michael Glassford <glassfordm_at_[hidden]> wrote:
> Peter Dimov wrote:
> > Michael Glassford wrote:
> >
> > [...]
> >
> > I'll think about your suggestion a bit more before I'll be able to
> > comment, but just a quick note:
> >
> >> l = m.lock();
> >> //Lock mutex m (first unlocking whatever mutex l was previously
> >> locking, if any)
> >
> >
> > This is not what will happen. m.lock() is executed first, then operator=
> > is called and l is given the opportunity to release its lock. So if l
> > happens to already hold m.lock(), the thread will deadlock. (And a
> > deadlock can also occur if another thread holds a lock on m and is
> > blocked on the mutex currently locked by l.)
> Actually, the comment in my pseudo-code above is an oversimplification
> of what I was actually thinking would happen. The actual transfer
> mechanism (when transfering from a mutex, at least) would be that the
> mutex would not actually be locked until the information was extracted
> from the lock_transfer object; the steps would be:
> 1) The mutex would build a lock_transfer object containing enough
> information to lock the mutex (this could be as simple as a this pointer
> and a member function pointer, either "raw" or using boost::bind or
> boost::function).
> 2) The lock_transfer object would be passed to the lock object's
> construtor or operator=.
> 3) The lock object would unlock itself if it's locked.
> 4) The lock object would extract the information from the lock_transfer
> object, which would lock the mutex in the process.
> This would also have the advantage that, if the information is never
> extracted from the lock_transfer object (for example, if mutex.lock()
> were called but the result were not assigned to a lock object), the
> mutex would never be locked.

What is happenning on concurrent m.lock() invocations with the lock
transfer object and their subsequent simultaneous use?


Boost list run by bdawes at, gregod at, cpdaniel at, john at