threads

[wg]

Hi Leute,

gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2
aktiv wird?
Im thread selber kann ja die Kontrolle abgeben werden mit einen I/O,
sleep u.ä.

Dake für Tipps,
wg

[Vinzent Hoefler]

wg wrote:

> gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2
> aktiv wird?

Mit einem entsprechenden Lock, ja.


Vinzent.

--
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.
-- Nathaniel Borenstein

[wg]

On 24.09.2012 22:08, Vinzent Hoefler wrote:
> wg wrote:
>
>> gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2
>> aktiv wird?
>
> Mit einem entsprechenden Lock, ja.
>
>
> Vinzent.
>

OK, dazu muss ich thread 2 über lock oder queue steuern.
Da ich aber thread 2 an *beliebiger* Stelle von *thread 1* aus anhalten
will, kommt ich das so nicht machen.

Gibt's eine Möglichkeit, den GIL (von python aus) zu beeinflussen?
Und zwar in der Form, daß thread 1 den GIL-State für sich beansprucht.
Das C-API hat so eine Funktion:
PyGILState_STATE PyGILState_Ensure()

Wolf

[Diez Roggisch]

On 9/25/12 9:34 AM, "wg" <w...@gmx.net> wrote:

>On 24.09.2012 22:08, Vinzent Hoefler wrote:
>> wg wrote:
>>
>>> gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2
>>> aktiv wird?
>>
>> Mit einem entsprechenden Lock, ja.
>>
>>
>> Vinzent.
>>
>OK, dazu muss ich thread 2 über lock oder queue steuern.
>Da ich aber thread 2 an *beliebiger* Stelle von *thread 1* aus anhalten
>will, kommt ich das so nicht machen.

Beliebig gibt's nicht. Wenn der Thread im C-Callstack steht, wird der
ausgeführt.

>
>Gibt's eine Möglichkeit, den GIL (von python aus) zu beeinflussen?
>Und zwar in der Form, daß thread 1 den GIL-State für sich beansprucht.
>Das C-API hat so eine Funktion:
>PyGILState_STATE PyGILState_Ensure()

Nichts offizielles, das ist bestenfalls ein hack. Du kannst natürlich
versuchen, über ctypes an's GIL zu kommen.

Und muss diese Salami-Taktik bei der Problembeschreibung sein? Das
beständige Glaskugelwetzen ist anstrengendŠ

Diez

[wg]

On 25.09.2012 11:08, Diez Roggisch wrote:
> On 9/25/12 9:34 AM, "wg" <w...@gmx.net> wrote:
>
>> On 24.09.2012 22:08, Vinzent Hoefler wrote:
>>> wg wrote:
>>>
>>>> gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2
>>>> aktiv wird?
>>>
>>> Mit einem entsprechenden Lock, ja.
>>>
>>>
>>> Vinzent.
>>>
>> OK, dazu muss ich thread 2 über lock oder queue steuern.
>> Da ich aber thread 2 an *beliebiger* Stelle von *thread 1* aus anhalten
>> will, kommt ich das so nicht machen.
>
> Beliebig gibt's nicht. Wenn der Thread im C-Callstack steht, wird der
> ausgeführt.
>
>
>
>>
>> Gibt's eine Möglichkeit, den GIL (von python aus) zu beeinflussen?
>> Und zwar in der Form, daß thread 1 den GIL-State für sich beansprucht.
>> Das C-API hat so eine Funktion:
>> PyGILState_STATE PyGILState_Ensure()
>
> Nichts offizielles, das ist bestenfalls ein hack. Du kannst natürlich
> versuchen, über ctypes an's GIL zu kommen.

Hast dafür evtl. Hinweise/Links wie sowas gehen könnte?

>
> Und muss diese Salami-Taktik bei der Problembeschreibung sein? Das
> beständige Glaskugelwetzen ist anstrengendŠ
>
> Diez
>
>

Ja, hast recht (Glaskugel?wetzen?);

ich wolle nur niemanden mit folgender Aufgabenstellung langweilen:
Thread 1 mit GUI, Daten werden von thread 2 via queue geliefert.
Thread 1 kann mit Button (oder Key) thread 2 *an belibeiger* Stelle
pausieren lassen.

Wird wohl ein C-framework dafür notwendig sein.

Wolf

[Vinzent Hoefler]

wg wrote:

> ich wolle nur niemanden mit folgender Aufgabenstellung langweilen:
> Thread 1 mit GUI, Daten werden von thread 2 via queue geliefert.
> Thread 1 kann mit Button (oder Key) thread 2 *an belibeiger* Stelle
> pausieren lassen.

Jetzt muß ich doch mal blöd fragen: Wozu? Wenn die Queue voll ist,
wird Thread 2 doch ohnehin angehalten, weil er nix mehr schreiben kann.
Damit wäre es von Thread 1 aus am einfachsten, die Queue nicht mehr
auszulesen, um Thread 2 schlafen zu legen.

Notfalls kann man auch an der Queue-Semantik ein wenig rumschrauben
und dort etwas wie "jetzt keine Nachrichten mehr akzeptieren, auch
wenn Queue noch nicht voll ist" implementieren.

[wg]

On 25.09.2012 12:23, Vinzent Hoefler wrote:
> wg wrote:
>
>> ich wolle nur niemanden mit folgender Aufgabenstellung langweilen:
>> Thread 1 mit GUI, Daten werden von thread 2 via queue geliefert.
>> Thread 1 kann mit Button (oder Key) thread 2 *an belibeiger* Stelle
>> pausieren lassen.
>
> Jetzt muß ich doch mal blöd fragen: Wozu? Wenn die Queue voll ist,
> wird Thread 2 doch ohnehin angehalten, weil er nix mehr schreiben kann.
> Damit wäre es von Thread 1 aus am einfachsten, die Queue nicht mehr
> auszulesen, um Thread 2 schlafen zu legen.
>
> Notfalls kann man auch an der Queue-Semantik ein wenig rumschrauben
> und dort etwas wie "jetzt keine Nachrichten mehr akzeptieren, auch
> wenn Queue noch nicht voll ist" implementieren.
>
>
> Vinzent.
>

Das ist eine realtime Videoüberwachung und der workerthread 2 führt
Aktionen durch, die u.U. vom GUI aus *sofort* angehalten werden sollen.
Der thread 2 ist tief verschachtelt, eine Abfrage 'kann i weitermachen'
müsste an vielen Stellen eingebaut werden.

Wolf

[Diez Roggisch]

Angehalten oder abgebrochen? Wenn letzteres, dann vielleicht doch besser
über das Modul multiprocessing gehen + einfach den Subprozess töten.

Und in Antwort auf deine andere Mail: nein, ich habe da keinen
Beispielcode, und ich zweifele auch ein bisschen an der Durchführbarkeit.

Eine Garantie für dieses Verhalten kann es letztlich auch mit dem GIL
nicht geben, denn wie gesagt - wenn du dich da in einem C-Callstack
befindest, dann hat das GIL da keinen Einfluss mehr.

Da ist Prozess töten wirklich die bessere Alternative.

Diez

[Christian Heimes]

Am 25.09.2012 13:52, schrieb Diez Roggisch:
> Angehalten oder abgebrochen? Wenn letzteres, dann vielleicht doch besser
> über das Modul multiprocessing gehen + einfach den Subprozess töten.
>
> Und in Antwort auf deine andere Mail: nein, ich habe da keinen
> Beispielcode, und ich zweifele auch ein bisschen an der Durchführbarkeit.
>
> Eine Garantie für dieses Verhalten kann es letztlich auch mit dem GIL
> nicht geben, denn wie gesagt - wenn du dich da in einem C-Callstack
> befindest, dann hat das GIL da keinen Einfluss mehr.

Diez hat absolut recht.

Das gewünschte Verhalten ist mit threads nicht umsetzbar. Wenn du einen
Programmablauf zu jeder Zeit, sofort und zuverlässig beenden willst,
dann musst du einen weiteren Prozess verwenden. Nicht mal
pthread_cancel() oder pthread_kill() garantieren ein verlässliches und
zeitnahes beenden eines Threads. Mal abgesehen davon, dass bei
pthread_kill() dein Programm in einem undefinierten Zustand hängen wird.

Dein Problem ist unabhängig von Python und ist auch mit reinem C-Code
nicht umsetzbar. Selbst bei Prozessen geht es mit SIGTERM, SIGKILL,
SIGSTOP / SIGCONT nicht zuverlässig synchron.

Christian

[wg]

Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das
was ich will.
Detto Siganlhandling. Nur gibt's unter Windows kein SIGSTOP, SIGCONT,
SIGUSER1/2 etc; das geht nur auf Nixen.

Also wird's wohl eine C-nahe Lösung werden.

Danke für deinen Kommentar.
Wolf

[wg]

thread stop/run ist gefordert, auf Interpreterlevel.
Eine Variante mit python:
win32process.SuspendThread(thread)
win32process.ResumeThread(thread)
Nur daß so unter bestimmten Umständen das GUI hängenbleibt.

Daher ist eine C/Python-Anwendung wahrscheinlich der beste Weg.
Oder aber man nehme anstelle von threads Prozesse, wie du vorschlägst.

Danke für deine Kommentare,
Wolf

[Christian Heimes]

Am 25.09.2012 17:39, schrieb wg:
> Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das
> was ich will.
> Detto Siganlhandling. Nur gibt's unter Windows kein SIGSTOP, SIGCONT,
> SIGUSER1/2 etc; das geht nur auf Nixen.
>
> Also wird's wohl eine C-nahe Lösung werden.

SuspendThread() ist keine C/C++ spezifische Funktion sondern ein Teil
der win32 Threading API. Die Funktion stoppt mitnichten den Thread
synchron (nur user-mode code) und ist auch nicht für Produktionscode
gedacht. Das ist ein gefährliches Debuggingfeature.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686345%28v=vs.85%29.aspx

[Vinzent Hoefler]

wg wrote:

> Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das
> was ich will.

Jau. Inklusive der damit verbundenen Deadlocks, wenn man nicht höllischst
aufpaßt. Was ein Grund ist, warum es aus den meisten APIs wieder rausgenommen
wurde (Java, Delphi), wenn es dort denn überhaupt jemals drin war und
mindestens als "deprecated" gekennzeichnet ist.

Kurz gesagt: Pfoten weg.

[Vinzent Hoefler]

wg wrote:

> Das ist eine realtime Videoüberwachung und der workerthread 2 führt
> Aktionen durch, die u.U. vom GUI aus *sofort* angehalten werden sollen.

Sofort ist relativ.

Facts for fun: Bei üblicher Nervenleitgeschwindigkeit vergehen inklusive
der Muskelbewegung und taktilem Feedback auch bei Schnellklickern locker
30 ms, bis die gesamte Signalstrecke Großhirn -> Zeigefinger -> Großhirn
überwunden ist.

Anders gesagt hat der Rechner schon ca. 20 ms Zeit, bevor der User überhaupt
selbst merkt, daß er tatsächlich geklickt hat. 20 ms allerdings sind auf
halbwegs modernen Rechnern mittlerweile so was wie eine Ewigkeit, selbst mit
interpretierten Sprachen.

> Der thread 2 ist tief verschachtelt, eine Abfrage 'kann i weitermachen'
> müsste an vielen Stellen eingebaut werden.

Nein, nur in der inneren Schleife. ;)

["Martin v. Löwis"]

Am 25.09.2012 17:39, schrieb wg:

>> Dein Problem ist unabhängig von Python und ist auch mit reinem C-Code
>> nicht umsetzbar. Selbst bei Prozessen geht es mit SIGTERM, SIGKILL,
>> SIGSTOP / SIGCONT nicht zuverlässig synchron.
>>
>> Christian
>>
>>
> Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das
> was ich will.

Es kann sein, dass es das macht, was Du willst - aber nicht, was Du
gesagt hast dass Du willst.

SuspendThread garantiert nicht, dass der Zielthread *sofort* angehalten
wird. Es kann schon sein, dass er u.U. noch etliche Takte weiterrechnet,
bevor er angehalten wird. Vielmehr wird für den Zielthread lediglich
der Suspend-APC beantragt, der dann "demnächst" den Thread auch anhält.

Ciao,
Martin

[wg]

Ja, Martin, das ist klar.
Wie schon in einem vorigen Posting erwähnt, ist der Begriff *sofort* von
mir missverständlich verwendet worden. Es genügt vollauf, wenn der Stop
ein paar Takte später erfolgt.

Danke,
Wolf

[wg]

On 25.09.2012 18:30, Vinzent Hoefler wrote:
> wg wrote:
>
>> Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das
>> was ich will.
>
> Jau. Inklusive der damit verbundenen Deadlocks, wenn man nicht höllischst
> aufpaßt. Was ein Grund ist, warum es aus den meisten APIs wieder
> rausgenommen
> wurde (Java, Delphi), wenn es dort denn überhaupt jemals drin war und
> mindestens als "deprecated" gekennzeichnet ist.
>
> Kurz gesagt: Pfoten weg.
>
>
> Vinzent.
>

Nur keine Angst vor Software :-) und 'höllisch aufpassen' is normal wenn
man programmiert.

Danke für deine Warnungen.
Wolf