2012-04-09 7 views
5

Mam prosty fragment deterministycznej pracy, która wymaga wykonania tylko trzynastu instrukcji maszynowych. Ponieważ pierwsza instrukcja przyjmuje domowy semafor (spinlock) i ostatnia instrukcja go wypuszcza, jestem bezpieczny od wszystkich innych wątków działających na innych rdzeniach, które próbują wykonać i dają ten sam semafor.W jaki sposób można uniknąć prewencji mojego wątku w trybie użytkownika

Problem pojawia się, gdy jakaś nitka przerywa wątek trzymający semafor, zanim zakończy swoją "sekcję krytyczną". Najgorszy przypadek to przerwanie zabijające wątek podczas trzymania semafora lub, jak może się zdarzyć, jeden z wątków zwykle rywalizujących o semafor rozgałęzia się na kod, który może generować przerwanie powodujące zakleszczenie.

Nie mam sposobu synchronizacji z tymi innymi wątkami, gdy rozgałęziają się na te części kodu, których nie mogę kontrolować. Myślę, że muszę wyłączyć przerwania, tak jak robiłem to w moich dawnych czasach VxWorks, kiedy pracowałem w trybie jądra. Jego zawsze trzynaście instrukcji i zawsze jestem całkowicie bezpieczny, jeśli mogę wykonać wszystkie trzynaście instrukcji, zanim będę musiał uszanować przerwanie. Aha, i to są moje własne wewnętrzne dane, inne, że domowy semafor nie ma nic, co blokuje cokolwiek innego.

Przeczytałem kilka odpowiedzi, które uważam za bliskie. Większość ma do czynienia z wywoływaniem sekcji krytycznych w interfejsie API systemu Windows (niewłaściwy system operacyjny, ale może odpowiednia koncepcja). Większość złych rozwiązań zakłada, że ​​mogę uzyskać wszystkie obraźliwe wątki, aby użyć muteksu, który tworzę z bibliotekami pthread.

Potrzebuję tego rozwiązania w C/C++ w systemach Linux i Solaris. Pytanie

Johnny Crash jest bardzo blisko prevent linux thread from being interrupted by scheduler

KermitG również Can I prevent a Linux user space pthread yielding in critical code?

Dzięki za uwagę.

+3

Użyj muteksów z biblioteki wątków (pthread) i uważnie przeczytaj dokumentację. Nie wdrażaj własnych prymitywów synchronizacji. Programowanie równoległe jest trudne :) –

+1

@ RafałRawicki: "Nic nie rób, bo to trudne." Może po prostu musi, bo muteksy są bzdurne. – Cartesius00

+0

możliwy duplikat [zapobiec przerywaniu wątku linuxowego przez program planujący] (http://stackoverflow.com/questions/2595735/prevent-linux-thread-from-being-interrupted-by-scheduler) –

Odpowiedz

3

Użytkownik może nie zapobiegać wyłączeniu wątku trybu użytkownika. Sekcje krytyczne (i wszystkie inne obiekty synchronizacji) zapobiegają kolizjom wątków, ale w żaden sposób nie zapobiegną ich uprzedzeniu przez system operacyjny.

Jeśli inne wątki oddział w coś po przekroczeniu tego limitu, podczas gdy coś może doprowadzić do impasu - masz problem projektowania.

Prawidłowy projekt powinien być najbardziej pesymistyczny: zawsze może wystąpić nakaz na czas nieokreślony.

+0

Dalsze badania doprowadziły mnie do wbudowane funkcje atomowe dostarczane przez kompilatory. Na przykład instrukcja GCC 4.7, sekcja 6.52 odnosi się do operacji atomowych. Uważam, że potrzebuję __atomic_thread_fence, ale nie jestem pewien, czy to zapewnia ochronę prewencyjną, której potrzebuję. – wapadomo

Powiązane problemy