Nutzung eines binären Semaphores für simples Erzeuger-Verbraucher-Problems

[Revan1710]

P1 kann nicht einfach "fröhlich weiter loopen", da sein eigener p() Aufruf während Prozess 2 noch am lesen ist P1 unterbrechen und an das der Ende der Warteschlange (der Semaphore, verwaltet vom OS) befördert

Das verstehe ich nicht. Nach dem exemplarischen Beispiel, würde die Loop von P1 ja dann in etwa so aussehen:

while(1)
{
    createNewImage();
    // ...
    p(sem);
    schreiben();
    v(sem);
}

Du hast ja dann schon eine Laufzeitabhängigkeit, die verhindern kann, dass sich nach dem Lesen P1 vor P2 einreiht oder nicht?

 

[ayngush]

Aber was spricht Dagegen:

while(1)
{
    p(sem);
    createNewImage();
    // ...
    schreiben();
    v(sem);
}

 

[Revan1710]

Natürlich wäre das für dieses Beispiel logisch, mir ging es ja absichtlich darum, dass der Thread noch irgendetwas zu tun hat zwischen v(sem) und p(sem). Das funktioniert ja dann wirklich nur, wenn P1 nach seiner Freigabe wieder direkt in Wartestellung geht.

@Cinematic
Ist das in blauer Schrift eigentlich eine Musterlösung?

 

[Cinematic]

Ja, ist eine Musterlösung. Aber ich habe auch schon erlebt, dass Musterlösungen fehlerhaft waren, bzw. hier in diesem Fall könnte ich mir vorstellen, dass die Lösung mit einer binären Semaphor tatsächlich nur funktioniert, wenn man bestimmte Voraussetzungen festlegt.

 

[Revan1710]

Ja das denke ich auch - die 2 Semaphoren-Lösung scheint aber definitv die bessere zu sein

 

[znep]

Hallo,

Die Lösung mit dem erwähnten "binären" Semaphor ist korrekt - wenn der denn richtig implementiert ist. Das ganze funktioniert dann folgendermaßen:

Producer
check(1) and acquire
write
decrease(-1) and release

Consumer:
check(0) and acquire
read
increase (1) and release

Der Producer kommt nur dran wenn der binäre Semaphor auf "1" steht und der Consumer bei "0". Dadurch funktioniert das Ping-Pong zwischen den beiden.

Grüße,
Znep