LINUX.ORG.RU

а вот Linux свободен от такого мракобесия %)

metawishmaster ★★★★★
()
Ответ на: комментарий от arsi

имхо ТС вот о чем: допустим есть процесс который захватил спин-блокировку, теперь если этот процесс попытается снова захватить эту же блокировку, то возникнет самоблокировка.

а вот в каких системах подобной самоблокировки не возникает — я не знаю)

ymn ★★★★★
()
Ответ на: комментарий от arsi

я о ядре (если придираться, то только оно Linux'ом и называется)

там подобное было в 200x, x < 5. Но его убрали.

а, ну да! PTHREAD_MUTEX - по-любому не spinlock ;)

metawishmaster ★★★★★
()
Ответ на: комментарий от ymn

ядро смотрело на current->pid, и если он был тем же, что уже удерживает, то пропускало лок

metawishmaster ★★★★★
()
Ответ на: комментарий от metawishmaster

PTHREAD_MUTEX - по-любому не spinlock ;)

Спинлок, если говорить о случае малого lock contention.

dmitry_vk ★★★
()
Ответ на: комментарий от ymn

а вот в каких системах подобной самоблокировки не возникает

Во всех. Блокировка обычно ставится не на процесс, а на абстрактный поток (которым может быть и нить, и процесс). Если lock holder уже удерживает блокировку, система должна либо бросить exception, либо просто игнорировать вызов оставив блокирвоку неизменной.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

либо просто игнорировать вызов оставив блокирвоку неизменной.

Просто игнорить нельзя, - приходиться учитывать число вызовов «lock», что-бы отпустить лок только после симметричного числа «unlock»-ов.

qrck ★★
()

В быдлокодерских, типа ms windows

ttnl ★★★★★
()
Ответ на: комментарий от no-dashi

Блокировка обычно ставится не на процесс, а на абстрактный поток (которым может быть и нить, и процесс).

Блокировка спинлока ставится на спинлок.

tailgunner ★★★★★
()

В JVM реентерабельные локи

maxcom ★★★★★
()
Ответ на: комментарий от no-dashi

Блокировка уже взятой в этом же потоке блокировки это алгоритмическая ошибка, вообще то

Я не спорю, я сам никогда не использую рекурсивных локов в своем коде.

qrck ★★
()
Ответ на: комментарий от no-dashi

no-dashi

Блокировка уже взятой в этом же потоке блокировки это алгоритмическая ошибка, вообще то

Не всегда.

Pavval ★★★★★
()
Ответ на: комментарий от CFA

CFA

В windows CRITICAL_SECTION рекурсивна. Хотя это конечно не спинлок в чистом виде.

Это вообще не спинлок. Это мьютекс (фьютекс, х...ютекс или что-либо подобное). Он по дефолту не спинится, я засыпает. А спин у него есть только как предварительная часть перед засыпанием, и только не больше заданного кол-ва проходов. И то, это надо отдельно включить.

Pavval ★★★★★
()

Сабж делается из обычного спинлока и per-thread атомарной переменной.

Pavval ★★★★★
()
Ответ на: комментарий от no-dashi

Во всех. Блокировка обычно ставится не на процесс, а на абстрактный поток (которым может быть и нить, и процесс). Если lock holder уже удерживает блокировку, система должна либо бросить exception, либо просто игнорировать вызов оставив блокирвоку неизменной.

Спинлок - это средство синхронизации процессоров в SMP а не процессов или потоков, поэтому встречая блокировку перепланирования не происходит а процессор в цикле ожидает ее освобождения, отсюда и название spin. На обычных ядрах двойная блокировка не опасна, с -rt патчем ядро рухнет на двойной блокировке.

bakugan
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.