Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Aug 2019 20:58:30 -0400
From:      Daniel Eischen <deischen@freebsd.org>
To:        Erich Dollansky <freebsd.ed.lists@sumeritec.com>
Cc:        freebsd-threads@freebsd.org, freebsd-questions@freebsd.org
Subject:   Re: mutex held in a thread which is cancelled stays busy
Message-ID:  <1FC05CEB-982F-484F-9E41-5A74FF564494@freebsd.org>
In-Reply-To: <20190806165429.14bc4052.freebsd.ed.lists@sumeritec.com>
References:  <20190806165429.14bc4052.freebsd.ed.lists@sumeritec.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Aug 6, 2019, at 4:54 AM, Erich Dollansky <freebsd.ed.lists@sumeritec.co=
m> wrote:
>=20
> Hi,
>=20
> for testing purpose, I did the following.
>=20
> Start a thread, initialise a mutex in a global variable, lock the mutex
> and wait in that thread.
>=20
> Wait in the main program until above's thread waits and cancel it.
>=20
> Clean up behind the cancelled thread but leave intentional the mutex
> locked.
>=20
> I would have expected now to get an error like 'EOWNERDEAD' doing
> operations with that mutex. But I get 'EBUSY' as the error.

Are you initializing the mutex as a robust mutex, via pthread_mutexattr_setr=
obust()?  Are you using _lock() or _trylock()?

For _trylock(), you only get EOWNERDEAD for robust mutexes.  It seems that y=
ou should get EOWNERDEAD for _lock() in this case, so if that's what you're d=
oing, it sounds like it might be a bug.

--
DE=




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1FC05CEB-982F-484F-9E41-5A74FF564494>