Re: Obscure mutex problem

Rainer Weikusat wrote:
David Given <dg@xxxxxxxxxxx> writes:
- when initially writing the code, I discovered that I had to set
PTHREAD_MUTEX_RECURSIVE to make the mutexes work at all... but then later
found this was no longer necessary. No doubt this is due to another
change I made, but I still don't understand it.

D'oh. I'm sorry, I managed to commit a typo in that paragraph, to vast confusion.

What I actually meant to say was that I had to set PTHREAD_PROCESS_SHARED. I
was finding that thread A would lock the mutex fine, and then thread B would
attempt to lock it, but instead of blocking would instead deadlock. *That* I
didn't understand. PTHREAD_PROCESS_SHARED made it work. Later when I went back
to try and figure out why it was necessary, I discovered it wasn't any more.

I use PTHREAD_MUTEX_RECURSIVE because I'm used to recursive mutexes from
elsewhere and would rather deal with mutexes set up the way I expect.

[...]
- my test machines include an ARM-based NSLU2 with linuxthreads (one kernel
process per thread) and a i386-based PC with NPTL (real kernel
threads).

Please don't perpetuate stupid myths about Linux threading
support.

Possibly slightly less inflammatory language, please?

In fact, I know full well the difference between tasks and processes and
threads --- I've been dealing with them professionally for years in other
environments. (Including writing, several times, user-space threading
libraries. Luckily that company went bust and I shouldn't have to do it any
more. Never again.) linuxthreads and NPTL are actually have some fairly major
differences under the hood, especially when it comes to TLS, and I thought it
was worth emphasising that I'd tried the program on both implementations and
it worked fine both ways. The fact that threads can be seen with ps in
linuxthreads and not in NPTL is simply the most user-visible indication of the
difference.

(In fact, the previous incarnation of spey used setcontext()/getcontext()
based coroutines, rather than the current coroutine emulation using pthreads.
It turns out that the TLS mechanism linuxthreads uses when there isn't any
kernel TLS support reacts really, really badly to applications trying to set
up user stacks, and as a result would curl up and die on 2.4 kernels. Sigh.)

[...]
Specifically, you will be able to determine which thread (if
any) has the mutex locked by locking at the owner member of the
corresponding structure.

Good idea. I'll see if I can find a volunteer to try that. (I wasn't
previously aware the owner tid was stored anywhere other than inside the
kernel...)

I should point out that the only difference between the foreground (working)
version and the background (non-working) version is that the background
version calls daemon(0,0). The user who found that out sent me comparative
straces of both versions, and they're practically identical, up until the
point where the background version deadlocks.

--
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───────────────────
│
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
.