Dnia Thu, 20 Jun 2013 03:35:33 -0700 po głębokim namyśle firr kenobi
rzekł:

> nie zmam sie za bardzo na rozmaitych prymitywach sluzacych do lockowania
> kawałków ramu (a jest tego kilkanascie z tego co kojarze) stad pytanie :
> czy najbardziej podstawowy z tych elementali (jak mniemam mutex) pozwala
> zapisac jakies informacje przy lokowamiiu jakiegos kawalka ramu (tak by
> inny watek ktory sie na to natkanł mogl to przeczytac) czy tez nie jest
> to praktykowane?

Mutex jest rozwiązaniem abstrakcyjnym, nie sprzętowym. W tym sensie,
że programista w każdej chwili może zapomnieć o mutexie i sprzęt
na to pozwoli.

Metainformacje w RAM istniały w starych Sunach, tagged data,
ale dotyczyły typu danych a nie wielodostępu. Technicznie
wykonalne, ale nie praktykowane. Nowe procesory mają mieć
wsparcie TM - specyfikacje i użycie już istnieją, tylko
samego sprzęta niet.

> drugie pytanie czy jest jakias (chocby zwyczajowa)
> hierarchia tych prymitywow i czy ich nazewnictwo juz sie jakos ulozylo
> czy tez panuja rozne nazewnictwa i jaki to jest ten standardowy set?

Mutex i lock to dwie nazwy tego samego pomijając może niuanse. Condition
variable jest praktycznie uniwersalną nazwą. W Win nazwy są takie same
jak nazwy ich metod - nie wiem. Są też praktyczne implementacje
tychże, takie jak Futex (na linuksie praktycznie w userspace
wszystkie mutexy są zaimplementowane przez futex, w kernelu
częściej jako spinlock)

Z podstawowych są też inne bestie: CAS, semafor, monitor (obudowany
cukrem mutex, odrobinę co innego), atomic sth, bariera, spinlock
i parę innych, w tym odmiany mutexów: rekursywne, RWLock.

Istnieje też abstrakcyjny Model Pamięci, bez którego wszystkie
powyższe nie mają najmniejszego sensu, oraz sprzętowy Model
Pamięci, bez którego nie dałoby się ich poprawnie zaimplementować.

Potem jest wiele elementów używających powyższych, jakby wyższego
poziomu: future, promise, continuation, asynchroniczność,
kontynuacje, egzekutory, Thread Pools, kolejki, struktury
danych lock-free, emulowane atomics (dla obiektów zbyt dużych
aby istniało sprzętowe wsparcie emuluje się na różne sposoby
semantycznie to samo używając innych operacji sprzętowych),
dzielone smart pointery, thread cancelation (aka ThreadDeath,
dziwna i himeryczna bestia), przekazywanie wyjątków pomiędzy
wątkami, once, jednorazowa statyczna inicjalizacja (wraz z
obleśnym double-checked locking), thread local storage,
same wątki i ich wszystkie odmiany - kompletna lista
byłaby znacznie dłuższa.

Wielowątkowość nie jest nowa, tylko relatywnie nowa w codziennym
masowym życiu programistów. Weszła masowo, gdy procesory
zaczęły mieć masowo najpierw HT a potem wiele rdzeni na
desktopie - co się stało niedawno, tylko kilka lat temu.

Powyższe są standardowym zestawem, natomiast większej hierarchii
w nich nie widzę.

--
Edek