|
|
Threads-Devel : |
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-04-14 11:02:35
Hi Frank,
----- Original Message -----
From: "Frank Mori Hess" <frank.hess_at_[hidden]>
To: "Discussions about the boost.thread library"
<threads-devel_at_[hidden]>
Sent: Monday, April 14, 2008 4:09 PM
Subject: Re: [Threads-devel] shared mutex locking discipline
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 14 April 2008 03:40 am, Anthony Williams wrote:
>> sides, as you point out. This only happens if you start with an
>> upgrade_lock on A, since otherwise you have to unlock the shared lock
>> before you can take the unique lock, and taking an upgrade lock should
>
> I don't think that is true, since you can smoothly transition from a
> shared_lock to an upgrade_lock. It's true upgrade_lock doesn't support
> moving a shared_lock into an upgrade lock, but you can transition from a
> shared to upgrade lock by doing:
>
> mutex_type m;
> shared_lock<mutex_type> shared(m);
> upgrade_lock<mutex_type> upgrade(m); (*)
> shared.unlock();
Your code deadlocks on (*). the upgrade_lock(Mutex&) constructor lock the
mutex that is already shared.
See the code
<code>
explicit upgrade_lock(Mutex& m_):
m(&m_),is_locked(false)
{
lock(); // <<<<<<<<<<<<<<<
}
upgrade_lock(Mutex& m_,bool do_lock):
m(&m_),is_locked(false)
{
if(do_lock)
{
lock();
}
}
<code/>
Best
____________________
Vicente Juan Botet Escriba
> - --
> Frank
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIA2WE5vihyNWuA4URAnoZAKDH1iKp+ZE3Pod4njD3ZI1McGLNPQCfaC8M
> Xap1foReZuku36JTt/VkS0E=
> =6Tjy
> -----END PGP SIGNATURE-----
> _______________________________________________
> threads-devel mailing list
> threads-devel_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/threads-devel
>