On 27.06.2013 22:58, A.L. wrote:
> On Thu, 27 Jun 2013 22:33:02 +0200, Michoo<m...@v...pl> wrote:
>
>>
>> Dyskusja dotyczyła podstawowego elementu synchronizacji. Semafor Dijskry
>> nie jest prostszy niż semafor binarny o semantyce test-and-set (który ma
>> wsparcie sprzętowe na większości współczesnych maszyn) a ma pewne
>> istotne wady (jak brak gwarancji na zagłodzenie). W praktyce implantacja
>> semafora _wymaga_ więc listy procesów oczekujących.
>>
>
> Obawiam sie ze nie zrozumiemy sie.

Też mi się tak wydaje:
dyskusja zaczęła się od różnicy czy podstawowym obiektem
synchronizacyjnym jest semafor uogólniony czy binarny o semantyce
test&set. Semafor uogólniony jest imo równoważny TS + chroniony licznik
co więcej na większości sprzętu realizuje się go jako "uogólniony" TS
(np wspomniane cmpxchg).


>
> P.S. Zadam to samo zadanko co kiedys: procesy a, b, c, d, e, f
>
> Wzajemne wykluczanie: (a,c), (c,f), (a,b), (b,e), (b,d), (c,d), (e,f)
>
> Zaprojeltowac rozwiazanie bez deadlocku i starvation free

Ale już Ci na nie odpowiadałem:
- tworzysz 6 muteksów (A-F)
- sporządzasz dla każdego procesu listę z którymi się wyklucza
- sortujesz te listy w kolejności a-f

Każdy proces wchodząc do sekcji krytycznej pobiera potrzebne mu blokady
w kolejności A-F. Rozwiązuje to problem wzajemnego wykluczania([*]).
Problem zagłodzenia nie wystąpi na pewno gdy muteksy budzą w kolejności
FIFO, przy braku tej gwarancji do zagłodzenia może dojść[**] więc
najlepiej chyba ją zapewnić przez kombinację mutex+lista+condition
variable (dopóki !pierwszy na liście).


[*] Czyim imieniem nazywamy ten algorytm - nie pamiętam. Jest to daleka
wariacja Lamporta.
[**] Choćby a i b "wymieniające się" muteksem A mogą zagłodzić c.

--
Pozdrawiam
Michoo