msgrcv konkurencia

Fórumok

adott egy program, amelyik uzenetsorba pakolja be (msgsnd) az adatokat (=fileneveket) - amig csak van feldolgozando file. Legyen 10 worker processz (hogy egy idoben ne csak 1 file feldolgozasa tortenjen, hanem 10-e), amelyik while(1) ciklusban kiolvassa (msgrcv) az uzenetsorbol a file-ok neveit, majd dolgozik vele, azutan johet a kovetkezo kovetkezot.

A kerdes az, hogy ha ez a 10 worker processz raszabadul az egy szem message queue-ra, akkor ugye nem tortenhet meg az, hogy 2 v. tobb processz is ugyanazt az uzenetet kapja meg?

Hozzászólások

subscribe, érdekel

Szerk:
Egyébként illenék kezelnie a konkurrens hozzáférést (elvégre az üzenetsorokat használhatod szinkronizációra), de konkrétan leírva ezt nem láttam sehol, bár annyira nem is kerestem.

Ilyen esetben amúgy - meg általában is ilyen méréseim voltak - az osztott memória + mutex kombináció gyorsabb lehet.

Szerk2:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%…

szerint thread safe

Szerk3:
Érdekes lehet:
http://www.linuxquestions.org/questions/red-hat-31/problem-with-msgrcv-…

Szerk4:
Meg ez is:
http://www.linuxmisc.com/9-unix-programmer/5a0cbe256474a07f.htm

Illetve - ha megteheted - körbenézhetsz mqueue terén, hátha jól jön.

megnezem az mqueue-t, kossz a tippet. De eloszor lesz par teszt a msgsnd/msgrcv parossal, ami pont azt tudja, ami nekem kell: a kuldo oldali 1 processzt blokkolja, amig tele van a queue, ill. a fogado oldali 10 processzek kozul blokkolva lesz az, amelyik nem tud kiolvasni adatot a queue-bol. Az shmem+mutex is tudja ezt egyszeruen?

Miert kell nekem sajnalnom a Klubradiot?

Csak röviden: nem történhet meg.

az mqueue kapcsan a sunos mq_receive(3C) ezt mondja:

"If more than one process (or thread) is waiting to receive a message when a message arrives at an empty queue, then the process of highest priority that has been waiting the longest is selected to receive the message."

Miert kell nekem sajnalnom a Klubradiot?