• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Dostęp do usuniętego mutexu

0 głosów
76 wizyt
pytanie zadane 21 czerwca w C i C++ przez RufinB Użytkownik (670 p.)
Załóżmy że mamy listę w której każdy węzeł ma własny mutex. W pierwszym wątku dochodzi do usunięcia pierwszego elementu tej listy dla tego następuje zablokowanie dwóch mutexow węzła pierwszego i następnego. W tym samym czasie w drogim wątku jakąś operacja próbuje także zablokować pierwszy mutex nie może więc czeka. Co zrobi kompilator po usunięciu węzła pierwszego w którym znajduje się mutex o którego zablokowanie ubiega się drugi wątek a który już nie istnieje
komentarz 21 czerwca przez overcq Pasjonat (17,750 p.)

W przykładzie podanym na tej stronie pod hasłem “Nes­ted Lo­c­king Wi­th a Sin­gly Lin­ked List” jest podane, że pierwszy element zawsze jest obecny.

3 odpowiedzi

+1 głos
odpowiedź 22 czerwca przez tangarr VIP (138,360 p.)
Jakikolwiek dostęp do listy powinien być zabezpieczony wspólnym mutexem. Jeżeli jeden wątek próbuje czytać/pisać po danych kasowanych w tym czasie przez inny wątek to w najlepszym razie dostaniesz błąd ochrony pamięci i program się wysypie. W gorszej sytuacji jeszcze inny wątek może przydzielić sobie tą pamięć i dostajesz błędy których nie da się łatwo namierzyć.
komentarz 27 czerwca przez mokrowski VIP (148,260 p.)
Wiesz co... nie zawsze. Taki gruboziarnisty (na cały kontener) mutex, będzie wąskim gardłem wydajności. Trzeba rozważyć co się dzieje z kontenerem w przypadkach zapisu (czyli jakiejkolwiek zmiany, również usunięcia elementu) i odczytu. Jak wpływają na siebie. I drugi aspekt to posiadanie elementu (ang. ownership). Który z wątków po zajęciu elementu posiada go na własność i może go zmieniać/niszczyć.

Po takich rozważaniach, wyjdzie Ci że potrzebujesz blokady zapis/odczyt (czyli w konwencji biblioteki standardowej shared: https://en.cppreference.com/w/cpp/thread/shared_mutex ). A do rozwiązania problemu zajęcia obiektu bezpiecznie, shared_ptr. I tak łatwo nie będzie, bo po zwolnieniu blokady na element która była wynikiem zajęcia na zapis/modyfikację/zniszczenie, trzeba sprawdzić shared_ptr, czy przypadkiem obiekt właśnie nie jest kandydatem na usunięcie (use_count() w shared_ptr) i rozsądnie zareagować. Problemów jest jeszcze kilka, rozwiązań także (choćby ze zmienną decyzyjną).

No chyba że wchodzimy na pole minowe lock free programming :) Ale tam zaczynają się problemy z konkretnymi architekturami i rodzajem dostępu do pamięci i synchronizacji.
0 głosów
odpowiedź 24 czerwca przez jankustosz1 Nałogowiec (31,100 p.)

https://en.cppreference.com/w/cpp/thread/mutex/~mutex

Usuwanie mutexów które mogą być zablokowane jest błędem i wszystko może się po tym wydarzyć. Rozumiem koncepcje, że chcesz mieć listę na której w jednym momencie można w różnych miejscach wykonywać operacje. O ile odczyt i modyfikacja wartości nie powinna być problemem, to usuwanie węzłów już chyba jest. Na pewno po odłączeniu węzła nie można od razu go usuwać. Kolejna rzecz jest, że zawsze po zrobieniu locka trzeba by jeszcze sprawdzać czy node nie został już usunięty, jeżeli tak to np. można odwołać się do listy i wykonać operację ponownie, lub być można właśnie o wartość z tego noda nam chodziło i wszystko będzie git? Jest tu dużo różnych aspektów które trzeba wziąć pod uwagę i łatwo się pomylić.

0 głosów
odpowiedź 26 czerwca przez mokrowski VIP (148,260 p.)
Dostęp do węzłów uzyskaj z użyciem std::shared_ptr

Podobne pytania

+2 głosów
1 odpowiedź 284 wizyt
0 głosów
1 odpowiedź 159 wizyt
0 głosów
2 odpowiedzi 310 wizyt

88,400 zapytań

137,011 odpowiedzi

305,796 komentarzy

58,656 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Sklep oferujący ćwiczenia JavaScript, PHP, rozmowy rekrutacyjne dla programistów i inne materiały

Oto dwie polecane książki warte uwagi. Pełną listę znajdziesz tutaj.

...