Здравствуйте, Videoman, Вы писали:

V>Здравствуйте, AlexGin, Вы писали:

AG>>Всё зависит от задач.
AG>>Я обычно мьютексы не использую, так как это "тяжёлые" системные объекты.
AG>>Насчет критических секций — не вижу ничего предосудительного в их применении.
AG>>Часто я аккуратно пользуюсь ими. Здесь важно — НЕ вводить в облась, защищенную секцией много кода:
AG>>

AG>>::EnterCriticalSection(m_pCS);
AG>>// Самые элементарные действия с общими ресурсами
AG>>::LeaveCriticalSection(m_pCS);
AG>>

V>Ну и зря. Под Windows, внутри Microsoft CRT, std::mutex не имеет ничего общего с WinAPI Mutex. Там, грубо, простой test_and_set, без захода в ядро.
Тогда отлично.
Можно им пользоваться достаточно спокойно!

AG>>Заполнять ядра CPU работой — это палка о двух концах:
AG>>При работе таких приложений, компьютер очень медленно реагирует на действия пользователя.
AG>>Правильнее — где-то в циклах рабочих потоков вводить ::Sleep(100...500);
AG>> — чтобы отдать управление системе (исключить жуткие тормоза для end-user-а).

V>Вот ни разу не встречал такого (только если не долбиться с тяжелым запросом в ядро в цикле).
Хорошо, — вот допустим, что у меня такой вариант "ожидания":

#include <atomic>
 
class SpinLock
{
public:
    void lock()
    {
        while(lck.test_and_set(std::memory_order_acquire)) // здесь, возможно, придется подождать!
        {}
    }
 
    void unlock()
    {
        lck.clear(std::memory_order_release);
    }
 
private:
    std::atomic_flag lck = ATOMIC_FLAG_INIT;
};

Взято отсюда:
http://anki3d.org/spinlock

Теперь предположим, что в результате некоторой ситуации все ядра моего CPU ждут на while в методе lock.
Да, случай практически не вероятный, но всё-таки — полностью НЕ исключаемый.
Загрузка всех секций CPU будет под 100% (здесь я даже не спрашиваю насчет полезноти/бесполезности данной вычислительной работы).
Спрошу только одно — сможет ли пользователь хоть как-то взаимодействовать с ОС? Хоть бы для того, чтобы снять эту зависшую задачу?

V>Всегда свои программы профилировали чтобы загрузка СPU была 100%. Если меньше, значит где-то холостые ожидания — значит код не оптимален, с точки зрения многопоточности.
+100500
Да, с точки зрения многопоточности НЕ оптимален.
Но если я вынужден буду только "топить Reset", чтобы хоть как-то вмешаться в работу системы, то такой код также не является корректным