Re: Obscure mutex problem

Rainer Weikusat wrote:
[...]
I do not quite understand why this would be regarded as
'inflammatory'. It's a technical fact. How can one get upset about
this? And I neither wrote about you-the-person nor did I mean to.

Unfortunately that turns out not to be the case. You accused me of
'perpetuating a stupid myth', which is strongly coloured and can be read as
implying that I'm doing it out of maliciousness. Part of the perils of a
text-only medium is there being no tone of voice --- I learnt the hard why why
it's always important to use moderate language for *everything* because it's
far too easy to be misread...

On the other hand, I have had one discussion with a 'NT-kiddie'
running around and telling everyone that 'Linux is inferior because it
does not support threads, but only processes', which had absolutely no
clue about anything, and I don't need another.

I entirely sympathise.

[...]
A guess would be that some thread locks the mutex before daemon forks
and because this thread isn't the one executing the fork, the locked
mutex in the child can never be unlocked again. At least that's the
specified behaviour. 'Some NPTL versions' support unlocking
mutexes from arbitrary threads, though.

I bet this is it. daemon(), of course, sneakily does a fork() behind the
scenes where it's not obvious. The *old* spey coroutine support, built with
getcontext()/setcontext(), didn't need mutexes and ran in a single thread, and
so wasn't affected by this.

I'm a little surprised that fork() doesn't duplicate the mutex along with the
rest of the process, though; it is, after all, no longer being allocated with
PTHREAD_PROCESS_SHARED, and so should be private. Unless the thread libraries
on which it is failing happen to share mutexes by default, of course... hmm.

Nevertheless, I shall rearrange the code and see what happens. Thanks very
much. I'll report back if it works or not.

--
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── 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
.

Relevant Pages

  • Re: Obscure mutex problem
    ... PTHREAD_MUTEX_RECURSIVE to make the mutexes work at all... ... mutex fine, and then thread B would attempt to lock it, but instead ... That pre-NPTL-Linux does not support 'real' multithreading 'but some ...
    (comp.os.linux.development.apps)
  • Re: Invoking external processes in threaded program
    ... is locked before the fork by a thread other than the forking thread, ... the child and so the thread that took the lock is no longer around to ... unlock the mutex. ... The problem is somewhat solvable for my own mutexes; ...
    (comp.unix.programmer)
  • Re: Re: little by little, Ahmad never contemplates until Catherine leads the sensible atom merrily
    ... hire wholly if Orin's fork isn't simple. ... It's very african today, I'll dispose shakily or Tariq will fling the ... It can already admit let alone Norm when the high beings support ...
    (sci.crypt)
  • Re: Invoking external processes in threaded program
    ... is locked before the fork by a thread other than the forking thread, ... the child and so the thread that took the lock is no longer around to ... The problem is somewhat solvable for my own mutexes; ...
    (comp.unix.programmer)
  • Re: RFC for a new Scheduling policy/class in the Linux-kernel
    ... at least in terms of supporting priority ... the mutexes which actually have PI enabled. ... I understand the need to support the ... seems that support for priority inheritance on mutexes has greatly ...
    (Linux-Kernel)