Forum: PC-Programmierung C / Linux: pthread_mutex_lock/unlock


von derguteweka (Gast)


Lesenswert?

Moin,

Ich haett' gerne mal ein Problem, un' zwar folgendes:

Einen wilden Buffer mit Daten, der von einem Thread geschrieben werden 
koennen soll, und von vielen anderen Threads gelesen werden koennen 
soll.

Dabei duerfen sich nur der Schreibthread und die Lesethreads nicht in 
die Quere kommen. Mehrere Lesethreads koennen ruhig "gleichzeitig" auf 
den Buffer zugreifen.

Schuetz' ich das jetzt mit einem klassischen pthread_mutex_lock/unlock, 
dann kann ja auch immer bloss ein Lesethread auf den Buffer zugreifen - 
gibts da irgendeine Mutex-Art oder irgendein Mutex-Attribut, mit dem man 
sowas regeln kann?  Koennte da "PTHREAD_MUTEX_RECURSIVE" in die richtige 
Richtung gehen?

Gruss
WK

von Oliver S. (oliverso)


Lesenswert?

Hm. Da du ja nun wenig dazu schreibst, mit welchem Compiler auf welchem 
OS du unterwegs bist, gibt es nur die Antwortkombination 
Google/Wikipedia:

https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock

Unter Implementations wird dir vielleicht geholfen.

Oliver

von Peter II (Gast)


Lesenswert?

Oliver S. schrieb:
> Hm. Da du ja nun wenig dazu schreibst, mit welchem Compiler auf welchem
> OS du unterwegs bist,

Betreff: C / Linux

von Derwoichbin (Gast)


Lesenswert?

Moin,

du lockst den Zugriff auf den Buffer nur dann und in der Funktion, in 
der du was rein schreibst/änderst.

Primitives Beispiel (ich nehme an du nutzt pthreads, aber sinngemäß ist 
es immer das gleiche):

pthread_mutex_lock(&mutex);
...
hier der Kram der den Buffer verändert
...
pthread_mutex_unlock(&mutex);



Nebenläufiges oder paralleles lesen brauchst du i.d.R. nicht locken.

von Sebastian V. (sebi_s)


Lesenswert?

Derwoichbin schrieb:
> Nebenläufiges oder paralleles lesen brauchst du i.d.R. nicht locken.

Naja nicht so wirklich. Wenn die writes atomar sind brauch ich fürs 
lesen natürlich kein lock aber dann brauch ich fürs schreiben vermutlich 
auch keins.

von unbekannt (Gast)


Lesenswert?

doch er muss auch beim lesen einen mutex setzen, sonst weiss der schreib 
thread nicht, ob er einen leseprozess stört (Daten werden während sie 
gelesen werden geändert).
ich würde das über ein public subscribe verfahren machen.
eine dynamische list mit lese channels, wo sich lese threads anmelden 
müssen.
wenn jetzt ein lese thread lesen möchte muss er seinen channel per mutex 
sperren. wenn der schreibprozess etwas schreiben möchte muss er warten 
bis alle lesechannels ihren mutex freigegegeben haben. und zusätzlich 
würde ich noch ein schreibe mutex setzen, damit leseprozesse keinen 
neuen mutex setzen und das System damit vom schreiben blockieren.

von Sebastian V. (sebi_s)


Lesenswert?

unbekannt schrieb:
> ich würde das über ein public subscribe verfahren machen. ...

Man braucht ja nicht das Rad ständig neu zu erfinden. Er nutzt doch 
schon pthreads also kann er dann auch 
pthread_rwlock_rdlock/pthread_rwlock_wrlock nutzen.

von derguteweka (Gast)


Lesenswert?

Moin,

Heissen Dank; da gibts ja was passendes von Ratiopharm:

pthread_rwlock_init(), _rdlock(), _wrlock(), _unlock(), _destroy()

Das scheint ja wie fuer mich gemacht...

Gruss
WK

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.