2013-06-14 14 views
7

Próbuję utworzyć wspólną pamięć, która będzie używana przez wiele procesów. te procesy komunikowania się ze sobą za pomocą połączeń MPI (MPI_Send, MPI_Recv).Nazwany semafor lub stado, które jest lepsze C linux

Potrzebuję mechanizmu kontrolującego dostęp do tej współużytkowanej pamięci Dodałem wczoraj pytanie, aby sprawdzić, czy MPI zapewnia jakiekolwiek narzędzie do tego. Shared memory access control mechanism for processes created by MPI, ale wydaje się, że nie ma takiego przepisu przez MPI.

Muszę wybrać między named semaphore lub flock.

Dla nazwanego semafora, jeśli jakikolwiek proces zginie nagle, bez wywoływania sem_cloe(), ten semafor zawsze pozostaje i można go zobaczyć przez ll /dev/shm/. Powoduje to czasem zakleszczenie (jeśli ponownie uruchomię ten sam kod!), Z tego powodu obecnie myślę o używaniu stada.

Chciałbym tylko sprawdzić, czy najlepiej nadaje się do tego rodzaju operacji flock?

Czy są jakieś wady korzystania z flock?

Czy jest coś jeszcze oprócz named semaphore i flock, których można tu użyć?

Pracuję nad C pod Linuksem.

Odpowiedz

8

Możesz także użyć muteksu POSIX we wspólnej pamięci; musisz najpierw ustawić na nim atrybut "pshared". Zobacz pthread_mutexattr_setpshared. Jest to prawdopodobnie najbardziej bezpośredni sposób robienia tego, co chcesz.

Powiedziawszy, możesz również zadzwonić pod numer sem_unlink na swoim nazwanym semaforze, gdy wciąż go używasz. Spowoduje to usunięcie go z systemu plików, ale bazowy obiekt semafor będzie istnieć, dopóki ostatni proces nazywa sem_close na nim (co zdarza się automatycznie, gdy wychodzi procesowych lub awarii).

Mogę wymyślić dwie drobne wady korzystania z flock. Po pierwsze, nie jest to POSIX, więc sprawia, że ​​twój kod jest trochę mniej przenośny, chociaż uważam, że większość Uniksów implementuje go w praktyce. Po drugie, jest on zaimplementowany jako wywołanie systemowe, więc będzie wolniejszy. Zarówno pthread_mutex_lock, jak i sem_wait używają mechanizmu "futex" w systemie Linux, który wykonuje wywołanie systemowe tylko wtedy, gdy faktycznie trzeba czekać. Jest to tylko problem, jeśli często chwytasz i zwalniasz zamek.

+0

+1, ale chciałbym tylko dodać, że "stado" i podobne mechanizmy z pewnością nie są dobrym wyborem. Zostały one zaprojektowane w celu ochrony równoczesnego korzystania z plików i do niczego innego. W szczególności, jeśli nic nie dzieje się w pliku, nie jest on określony, gdy metadane pliku (takie jak zamki) są widoczne dla innych procesów. Po prostu nie używaj tego do celów, do których nie był przeznaczony. –