Linux за българи: Форуми

Програмиране => Общ форум => Темата е започната от: Oxy в Dec 04, 2011, 20:38



Титла: Спинлок синхронизация
Публикувано от: Oxy в Dec 04, 2011, 20:38
Здравейте! Спинлок е възможно решение на Проблема с критичната секция. Понеже не уча на български не съм наясно кое как се превежда затова обяснявам малко по-широко: Дадена е програма която има част, която подлежи на паралелизиране чрез спинлок. Спинлокът е реализиран по следния начин:

while( key) Swap(&lock, &key);

прието е че Swap() е атомарна инструкция с хардуерна реализация. Въпросът който не ме интересува и не мога да му намеря отговор е : Защо въпросната реализация може да доведе до намаляване на производителността при мултипроцесорна система?


Титла: Re: Спинлок синхронизация
Публикувано от: gat3way в Dec 04, 2011, 21:46
Сигурен ли си че въпросната реализация може да доведе до намаляване на производителността на мултипроцесорна, а не на еднопроцесорна система? Виж внимателно какво са написали - ако наистина става въпрос за многопроцесорна система и аз ще бъда доста любопитен.



Титла: Re: Спинлок синхронизация
Публикувано от: Oxy в Dec 05, 2011, 00:18
Ето как е зададена задачата.
A spinlock might be implemented using the following code:
while( key ) Swap(&lock, &key) ;
Why can this code exhibit poor performance on modern multiprocessor systems?

Предвид, че инструкцията е атомарна, не се налага да се забранят интеруптите(решение при не атомарни инструкции при еднопроцесорна система).

Евентуално си мисля в случай в който има повече нишки от процесори може да се получи следната ситуация: Един процесор да вземе лок върху критичната секция, и да кара другите процесори които също искат да влязат в нея да спинват и реално само 1 процесор да работи, докато другите чакат...


Титла: Re: Спинлок синхронизация
Публикувано от: gat3way в Dec 05, 2011, 00:35
Да ама представи си колко по-зле ще е на еднопроцесорна система (където има preemption разбира се, иначе ще цикли безкрайно). Ако един или няколко процеса чакат да се отключи, докато някой го е заключил и е бил preempt-нат преди да го отключи, сума ти timeslice-а ще бъдат похабени изцяло докато на държащият lock-а процес му се даде процесорно време да го освободи. Това е щото цикленето и atomic exchange-а не са блокиращи операции и държат процеса в running state.