mehr zu deadlocks (was: linux-l: fork() problem mit omniorb)

[Steffen Dettmer]

* Jan-Benedict Glaw wrote on Tue, Nov 28, 2000 at 16:31 +0100:
> On Tue, Nov 28, 2000 at 11:07:26AM +0100, Steffen Dettmer wrote:
> > * Jan-Benedict Glaw wrote on Mon, Nov 27, 2000 at 12:09 +0100:
> > > Schreib' doch bitte nochmal genau auf, *wer* *wen* *wie* und in
> > > welcher Reihenfolge etc. aufruft...

> >     for (;;) {
> >         timet = time(NULL);
> >         asctime(localtime(&timet));
> >         if (lasttimet!=timet) {
> >             printf("main still alive, sigcount: %d...", sig_count);
> >             printtime(timet);
> >             lasttimet=timet;
> >         }
> >     }
> 
> *grusel* busy waiting...

Ja, oft asctime, localtime und time aufrufen, um die
race-condition zu provozieren. Hab ich ja geschrieben:

> > sollte dann irgentwann schiefgehen. Leider scheint der P100 hier
> > dazu zu lahm, schließlich muß das signal genau dann kommen, wenn
> > main im asctime(...) call steckt. 
> 
> Das "Problem" liegt an anderer Stelle: Signale sind, wenn sie an
> Dein Programm herangetragen werden, wie flags. "gesetzt" oder
> "nicht gesetzt". 

Ja, ich weiß, in einer 32Bit breiten Bitmap, und?

> Wenn also Dein Perl-Programm 100mal das Signal
> setzt, aber Dein signalempfangendes Programm noch nicht von der
> CPU mit Rechenzeit begünstigt worden ist, dann "sieht" es nach
> dem 1005ten Signal nur, daß es "mindestens einmal" eingegangen ist...

Ja, und? Es wird aber in den signal handler gesprungen. Die
anderen signale stören dabei ja nicht.

> Insofern kann weniger (im Perl-Programm) hier mehr sein;)

?!? Was hat das jetzt mit dem Deadlock zu tun?
Das eigentliche Problem, das ich Eingangs schilderte, war ja, daß
in einer race-condition ein deadlock auftritt. "race" heißt in
production vielleicht einmal im Monat. Also entschieden zuviel
(weil mehr als null-mal im Monat).

Mal brainstorm: asctime arbeitet in einem static buffer.
Ergo ist es "erstmal" nicht reentrant, was nicht thread-fähig
ist. Um threadfähig zu werden, muß es also ein mutex machen, um
nicht von zwei Threads (desselben Prozeßes) aufgerufen zu werden.
Wenn nun aber derselbe Thread es zweimal startet, weil ein Aufruf
durch ein signal unterbrochen wurde, wartet ein Thread auf das
unlock desselben Threads, was nie passiert, weil der Thread an
einer anderen Stelle (eben dem signal handler) blockt.

Nun ist die Kundenplattform SuSE 6.3, also nützt es erstmal nix,
wenn das Problem mit der libc von 7.0 behoben ist.

Ich hoffe, daß Problem ist jetzt klarere, und hoffe, daß jemand
ne Idee hat...

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.