Re: mutex held in a thread which is cancelled stays busy
Erich Dollansky <[email protected]>
| Newsgroups | gmane.os.freebsd.questions,gmane.os.freebsd.devel.threading |
|---|---|
| Message-ID | <[email protected]> |
Hi, On Tue, 6 Aug 2019 20:58:30 -0400 Daniel Eischen <[email protected]> wrote: > > On Aug 6, 2019, at 4:54 AM, Erich Dollansky > > <[email protected]> wrote: > > > > Hi, > > > > for testing purpose, I did the following. > > > > Start a thread, initialise a mutex in a global variable, lock the > > mutex and wait in that thread. > > > > Wait in the main program until above's thread waits and cancel it. > > > > Clean up behind the cancelled thread but leave intentional the mutex > > locked. > > > > 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_setrobust()? Are you using _lock() or _trylock()? > > For _trylock(), you only get EOWNERDEAD for robust mutexes. It seems > that you should get EOWNERDEAD for _lock() in this case, so if that's > what you're doing, it sounds like it might be a bug. > I did both. One time with initialising the mutex with its defaults by handing over NULL as the attribute setting and one time with the attributes set. I use this line to set the attribute: pres = pthread_mutexattr_setrobust (& Attr, PTHREAD_MUTEX_ROBUST); The following line: pthread_mutexattr_getrobust (& Attr, &pres); Sets pres also to 1. I am doing this on 12.0-STABLE FreeBSD 12.0-STABLE r350391 GENERIC amd64 with the systems standard compiler. Is this the corrent way of doing it? Erich _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[email protected]"