Пара вопросов о Win32 CriticalSections

[tengiz]

Любопытно, что у меня и, насколько я могу судить, не только у меня сложилось мнение о spinlock'ed CS, как о способе сделать high contention lock масштабируемым. Что при внимательном рассмотрении оказывается не совсем соответствующим действительности. Хотя, с другой стороны - если количество потоков в системе в разы превышает количество процессоров, то такая система, видимо, сама по себе плохо масштабируется.

Проблема масштабируемости критической секции ведь не сводится только к конвоям? В случаях, когда доступ к критической секции имеет нерегулярный характер или когда за кририческую секцию конкурирует много потоков, но потокам она не нужна много раз в течение кванта, а также когда время, на которое захватывается CS очень маленькое (скажем, порядка или меньше времени переключения контекста), то правильно подобранный spincount может заметно снизить CPU utillization как раз в правильных случаях, когда количество потоков не очень сильно превышает количество процессоров.

[Big Cheese]

1)А слабо иметь копию кэша для каждого потока ? 2)Или 2-уровневый кэш: для каждого потока свой "маленький" кэш и один большой общий. Количество обращений к общему ресурсу сокращается, и он перестает быть "суперпопулярным".

1)Во-первых, надо будет поддерживать синхронность кэшей, что может свести на нет все преимущество. Во-вторых, такое решение неоптимально по памяти, и чревато возникновением проблем с увеличением объема данных...
2) В принципе, выглядит разумно, но сильно зависит от контекста, т.е. что, собственно, эти данные из себя представляют, и насколько эффективно и легко можно организовать их partitioning - "привязать" к потоку / поток - к ЦПУ и т.д. Мне, лично, это удается далеко не всегда...

[Big Cheese]

Проблема масштабируемости критической секции ведь не сводится только к конвоям? В случаях, когда доступ к критической секции имеет нерегулярный характер или когда за кририческую секцию конкурирует много потоков, но потокам она не нужна много раз в течение кванта, а также когда время, на которое захватывается CS очень маленькое (скажем, порядка или меньше времени переключения контекста), то правильно подобранный spincount может заметно снизить CPU utillization как раз в правильных случаях, когда количество потоков не очень сильно превышает количество процессоров.

Да, все так. Просто, для меня это было эээ... несколько не очевидно .

[Michael Popov]

1)Во-первых, надо будет поддерживать синхронность кэшей, что может свести на нет все преимущество. Во-вторых, такое решение неоптимально по памяти, и чревато возникновением проблем с увеличением объема данных...
2) В принципе, выглядит разумно, но сильно зависит от контекста, т.е. что, собственно, эти данные из себя представляют, и насколько эффективно и легко можно организовать их partitioning - "привязать" к потоку / поток - к ЦПУ и т.д. Мне, лично, это удается далеко не всегда...

1) Не надо Независимые кэши - это легко и красиво
2) Если потоки делают одну и ту же работу, то можно смело предоставлять каждому из них вести свой независимый кэш. И не надо ничего никуда привязывать.

А насчет неэффективного использования памяти : 64-бит эра на носу, да и производителям железа надо дать возможность заработать свой кусок хлеба с маслом