2013-06-14 6 views
7

Ich versuche, einen gemeinsamen Speicher zu erstellen, der von mehreren Prozessen verwendet wird. Diese Prozesse kommunizieren miteinander unter Verwendung von MPI Aufrufen (MPI_Send, MPI_Recv).Benannt Semaphor oder Flock, die besser ist C linux

Ich brauche einen Mechanismus, um den Zugriff auf diesen gemeinsamen Speicher zu steuern Ich habe gestern eine Frage hinzugefügt, um zu sehen, ob MPI irgendeine Möglichkeit bietet, das zu tun. Shared memory access control mechanism for processes created by MPI, aber es scheint, dass es keine solche Bestimmung von MPI gibt.

Also muss ich zwischen named semaphore oder flock wählen.

Für benannte Semaphore, wenn einer der Prozesse abrupt stirbt, ohne sem_cloe() aufzurufen, dann bleibt dieser Semaphor immer und kann von ll /dev/shm/ gesehen werden. Dies führt manchmal zu einem Deadlock (wenn ich denselben Code noch einmal ausfühle!). Aus diesem Grund denke ich momentan daran, flock zu verwenden.

Sie wollten nur bestätigen, ob flock für diese Art von Operation am besten geeignet ist?

Gibt es Nachteile bei der Verwendung von flock?

Gibt es noch etwas anderes außer named semaphore und flock, die hier verwendet werden können?

Ich arbeite an C unter Linux.

Antwort

8

Sie können auch einen POSIX-Mutex im gemeinsam genutzten Speicher verwenden; Sie müssen nur das "pshared" -Attribut zuerst setzen. Siehe pthread_mutexattr_setpshared. Dies ist wohl der direkteste Weg, um das zu tun, was Sie wollen.

Das heißt, Sie können sem_unlink auf Ihrem benannten Semaphor auch anrufen, während Sie es noch verwenden. Dadurch wird es aus dem Dateisystem entfernt, aber das zugrundeliegende Semaphorobjekt bleibt bestehen, bis der letzte Prozess sem_close darauf aufruft (was automatisch passiert, wenn der Prozess beendet wird oder abstürzt).

Ich kann zwei kleine Nachteile der Verwendung von flock vorstellen. Erstens ist es nicht POSIX, also macht es Ihren Code etwas weniger portabel, obwohl ich glaube, dass die meisten Unixes es in der Praxis implementieren. Zweitens wird es als Systemaufruf implementiert, also wird es langsamer. Sowohl pthread_mutex_lock als auch sem_wait verwenden den "futex" -Mechanismus unter Linux, der nur einen Systemaufruf durchführt, wenn Sie tatsächlich warten müssen. Dies ist nur ein Problem, wenn Sie das Schloss viel greifen und loslassen.

+0

+1, aber ich möchte nur hinzufügen, dass 'Flock' und ähnliche Mechanismen sicherlich keine gute Wahl sind. Sie sollen die gleichzeitige Verwendung von Dateien und nichts anderes schützen. Insbesondere, wenn nichts anderes in der Datei passiert, wird es nicht angegeben, wenn Dateimetadaten (wie Sperren) für andere Prozesse sichtbar sind. Benutze das nicht für einen Zweck, für den es nicht entwickelt wurde. –

Verwandte Themen