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
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
Oliver S. schrieb: > Hm. Da du ja nun wenig dazu schreibst, mit welchem Compiler auf welchem > OS du unterwegs bist, Betreff: C / Linux
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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.