Можно ли использовать вместо TCriticalSection.TryEnter TInterlocked.CompareExchange? В том числе под Linux. Нет ли

глюков?

Стикер

Нет нельзя - они отвечают за разные вещи

В моих экспериментах CriticalSection работала лучше и быстрее спинлоков на атомарных счетчиках. Но в то же время CriticalSection может сделать больно в DLL (нельзя использовать в инициализации) и не везде доступно TryEnter

Проблема в том что CriticalSection под линуксом реализована через TMonitor. А к нему мало доверия.

CS внутри на Винде - это комбинация спинлока в третьем кольце с заданным (можно изменить при создании) количеством итераций и ядерного Wait'а, если на уровне пользователя не получилось. И хороший результат виндового CS - в этой комбинации.

Почему?

У кого реализована? через pthread_mutex реализована так-то

в Delphi

Сорцы винды читал? :)

А, ну может быть, там не смотрел

Читал. Но это описано в Internals.

Это где?

Рихтер писал что атомарные ф-ии чувствительны к выравниванию данных по кэш линиям

Далеко не ты один их почитываешь))

Атомик не должен пересекать границу cache line. Ибо лочится все по ним

Да я ж не против, наоборот, парень очень крепко отвечает (и не первый раз), я себе даже пометочку сделал :)

В чем это выражается на практике? Есть какой-то шанс работать не с кэшем?

Ну тут же все написано https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange

Не нашел буквы "cache" в тексте

Александр (Rouse_) Багель
Между строк

Типа не надо использовать кривой и нестандартный мэнеджер памяти? Ну ок.

Там на самом деле очень интересные моменты, если есть возможность изучи исходники винды - там в некоторых местах ТААААК КРАСИВО сделано, причем сам алго рассчитан именно на выравнивание

Да меня больше работа в линукс интересует.

А, ну там не сильно в этом плане отличается, блокировка всеравно через LOCK делается :)

на x86 может дополнительно тормозить (хотя вроде должно работать). на других архитектурах может и поломаться

дело не в винде или линуксе, дело в том, как устроено железо

Это все интересно и загадочно, но как бы поближе к конкретике? :)

Да я спокоен. Нет проблем. :) ^ вот, собственно первый пост по теме.

Тогда - если смотреть на проблему из аппаратной области, проблемы в случае использования RTL обертки должны отсутствовать ибо она сделана с учетом всех нюансов

НО - отвечая на твой вопрос (причем во второй раз) так делать нельзя ибо перечисленное тобой применяется в двух разных сидуациях. Критсекция - это прямо вот когда кусок кода на исполнение залочить надо, а эксченж - это обычный безопасный трансфер массива данных под блокировкой. Они не взаимозаменяемы

Стикер

Нет, это значит, что выровненные на адрес значения под х86 меняются атомарно.

Так то одно есть прямое следствие другого.

Можно иметь сколь угодно прямой МП второго уровня и работать с полем внутри упакованной записи и т.п. А насчёт кривости МП - например, библиотека OTL прямо проверяет, как МП выравнивает блоки и крашится, если что-то не так, т.к. завязана на выравнивание в некоторых местах.

Ну я ж сказал cmpxcg требует в противном случае будет непонятное поведение