Koszt muteksu, sekcji krytycznej itp. W systemie Windows

Question

Czytałem gdzieś, że obciążenie mutexem nie jest zbyt duże, ponieważ przełączanie kontekstów odbywa się tylko w przypadku rywalizacji.

Znany również Futexes w systemie Linux.

Czy to samo działa dobrze w systemie Windows? Czy sekcja krytyczna jest bardziej trafną mapą do muteksów w Linuksie.

Z tego, co zebrałem, Sekcje krytyczne zapewniają lepszą optymalną wydajność w porównaniu do Mutex, czy to prawda w każdym przypadku?

Czy istnieje przypadek rogu, w którym muteksy są szybsze niż sekcja krytyczna w systemie Windows.

Załóżmy tylko jednym procesie gwinty są dostępu do muteksy (tylko w celu wyeliminowania innych korzyści krytycznych sekcje)

Dodane Info: system operacyjny Windows Server
Język C++

Answer 1

Zważywszy na szczególny cel Critical Sections i Mutexes Nie sądzę, że możesz zadać pytanie dotyczące kosztów, ponieważ nie masz zbyt wiele alternatyw, gdy potrzebujesz wielu wątków dotykających tych samych danych. Oczywiście, jeśli potrzebujesz po prostu zwiększyć/zmniejszyć liczbę, możesz użyć funkcji Interlocked*() na numerze volatile i możesz już iść. Ale dla czegoś bardziej złożonego, musisz użyć obiektu synchronizacji.

Rozpocznij czytanie tutaj na Synchronization Objects available on Windows^. Wszystkie funkcje są tam wymienione, zgrupowane i odpowiednio objaśnione. Niektóre z nich to tylko Windows 8.

Jak chodzi o Twoje pytanie, Critical Sections są tańsze niż Mutexe s, ponieważ są one przeznaczone do pracy w tym samym procesie. Przeczytaj this^ i this^ lub po prostu poniższy cytat.

Obiekt przekroju krytycznego zapewnia synchronizację podobną do tej zapewnianej przez obiekt mutex, z wyjątkiem tego, że sekcja krytyczna może być używana tylko przez wątki pojedynczego procesu. Obiekty zdarzeń, muteksów i semaforów mogą być również używane w aplikacji jednoprocesowej, ale obiekty sekcji krytycznej zapewniają nieco szybszy i bardziej wydajny mechanizm synchronizacji wzajemnego wykluczenia (specyficzny dla procesora test i instrukcja zestawu). Podobnie jak obiekt mutex, krytyczny obiekt sekcji może być własnością tylko jednego wątku na raz, co czyni go użytecznym do ochrony współdzielonego zasobu przed równoczesnym dostępem. W przeciwieństwie do obiektu mutex, nie ma możliwości stwierdzenia, czy sekcja krytyczna została porzucona.

użyć Critical Sections dla samej synchronizacji procesu i Mutexes synchronizacji przekroju procesu.Tylko gdy NAPRAWDĘ potrzebuję wiedzieć, czy obiekt synchronizacji został porzucony, używam Mutexów w tym samym procesie.

Tak więc, jeśli potrzeba synchronizacji obiektu, nie chodzi o to, jakie są koszty, ale który jest tańszy :) Tam naprawdę nie ma alternatywy, ale pamięć korupcja.

PS: Nie może być alternatywy, takie jak one mentioned in the selected answer here^ ale zawsze iść do podstawowej funkcjonalności platformy specyficzne vs. przekroju platformness. Zawsze jest szybciej! Więc jeśli używasz systemu Windows, korzystać z narzędzi systemu Windows :)

UPDATE

W zależności od potrzeb, może być w stanie zmniejszyć potrzebę obiektów synchronizacji, starając się robić jak najwięcej samo- zawierał pracę w wątku, jak to tylko możliwe, i łączył dane tylko na końcu lub co jakiś czas.

Głupi przykład: Zrób listę adresów URL. Musisz je zeskrobać i przeanalizować.

1. Wrzuć kilka wątków i zacznij wybierać adresy URL, jeden po drugim, z listy wejściowej. Dla każdego z nich scentralizujesz wyniki tak, jak to robisz. To jest w czasie rzeczywistym i fajne
2. Możesz też wrzucić wątki, z których każdy ma plaster wejściowych adresów URL. Eliminuje to potrzebę zsynchronizowania procesu selekcji. Przechowujesz wynik analizy w wątku, a na końcu łączysz wynik tylko raz. Lub powiedzmy co 10 adresów URL. Nie dla każdego z nich. Spowoduje to radykalne zmniejszenie operacji synchronizacji.

Koszty można więc obniżyć, wybierając odpowiednie narzędzie i zastanawiając się, jak obniżyć zamek i odblokować. Ale koszty nie mogą być usunięte :)

PS: Myślę tylko w adresach URL :)

UPDATE 2:

Gdyby potrzebne w projekcie, aby zrobić kilka pomiarów. A wyniki były dość zaskakujące:

• std::mutex jest najdroższe. (cena krzyżowego platformness)
• Okna rodzimy Mutex się 2x szybciej niż std.
• A Critical Section jest 2x szybszy niż natywny Mutex.
• SlimReadWriteLock wynosi ± 10% wartości Critical Section.
• Mój domowy InterlockedMutex (Spinlock) jest x1,25 - 1,75x szybciej niż Critical Section.

Answer 2

Używanie std :: mutex na windows 8 I zazwyczaj 3-4x poprawę (na non przypadku rywalizujących) przyspieszenie stosując własne zamówienie blokadę wirowania:

mutex oparty

auto time = TimeIt([&]() { 
for (int i = 0; i < tries; i++) { 
    bool val = mutex.try_lock(); 
    if (val) { 
     data.value = 1; 
    } 
} 

});

Home made zablokować darmowych

time = TimeIt([&]() { 
    for (int i = 0; i < tries; i++) { 
     if (!guard.exchange(true)) { 
      // I own you 
      data.value = 1; 
      guard.store(true); 
     } 
    } 
}); 

Testy wykonywane są na platformie x86.

Nie mam pojęcia, co std :: mutex używa podkreślenia w systemie Windows, ponieważ generuje wiele kodu.