netch80 wrote:
> C>Проблема в том, что если тебя за-preemt'ят пока ты держишь спинлок — то
> C>остальные потоки будут активно продолжать его крутить (офигительные
> C>потери производительности на SMP).
> Блин. Так потому спинлоки в их стандартном виде и не могут
> использоваться в среде с насильным preemption в принципе!
Так ведь используются (см. EnterCriticalSection) В user mode,
например, так вообще нельзя никак запретить preemption твоего потока.

> C>Нашел вот тут:
> C>http://en.wikipedia.org/wiki/Non-blocking_synchronization#Wait-freedom
> Ага. Так там есть замечательная цитата по поводу:
[skip]
> То есть перейти на них, конечно, можно, но результат будет ужасен (см.
> первое предложение). А по дальнейшему — так как вместо CAS и LL/SC
> ничего пока не придумали — то вообще думать в эту сторону смысла нет.
Ну да, в общем случае они действительно не подходят. А в
отдельных частных случаях зато дают огромные преимущества.

> C>Нет, нет и еще раз нет. Пока ты думаешь что делать с данными — ты НЕ
> C>держишь блокировок в lock-free. Другие потоки могут спокойно в него
> C>продолжать писать.
> А я, по-Вашему, о чём говорю?) Да, не держишь блокировок. Именно
> поэтому, когда ты уже пошёл менять данные так, как тебе нужно — будь
> готов, что данные к этому времени изменились и замена может обломиться.
Ээээ... Ты, видимо, не понимаешь сути lock-free. Данные обычно не меняют
(это тупо), обычно меняют контейнеры.

Соответственно, для большинства случаев ты просто берешь данные из
контейнера (атомарно) и делаешь с ними работу. Сами данные никто не
меняет, а состояние контейнера тебе пофиг.

> При одновременном входе с двух процессоров в случае мьютекса один
> процессор успеет быстрее другого сделать CAS на объект мьютекса
> а в случае lock-free — на общие
> данные, а второй будет или сонно, или решительно, но курить бамбук и
> уходить на следующий круг.
Проблема в том, что со спинлоком он будет курить бамбук все время,
пока ты делаешь работу. В случае с lock-free он будет курить бамбук
ровно 1 лишний цикл (если другой претендент ровно в этот же момент не
сделает операцию — но это очень маловероятно).

Поэтому вместо спинлока в highly contended коде нужно ставить мьютексы,
которые будут останавливать поток, а не увеличивать энтропию Вселенной зря.

> C>Собственно, та hash map масштабируется до 4 тысяч одновременно пишущих и
> C>читающих процессоров Неплохо, ИМХО.
> Не сказано, как меряли, в плане разнообразия данных. Если там в качестве
> ключей брались все строки разные — охотно верю. Если бы было много
> одинаковых — тормозило бы почище чем на локах.
Не тормозило бы