Просто в твоем примере между unlock и lock совсем нет никакого интервала ожидания и второй поток просто не успевает "воткнуться". Перенеси "sleep" в другую точку и ты увидишь что все вполне "fair":

http://coliru.stacked-crooked.com/a/fa63ab30045995d3

#include <iostream>
#include <thread>
#include <mutex>

std::mutex m;

void thd(const char* name)
{
    for (int i = 0 ; i < 4; i++)
    {
        
        std::this_thread::sleep_for(std::chrono::milliseconds(500));
        m.lock();
        std::cout << name << std::endl;
        m.unlock();
    }
}

int main()
{
    std::thread thd1(thd, "thread 1");
    std::thread thd2(thd, "thread 2");
    thd1.join();
    thd2.join();
}

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

R>Просто в твоем примере между unlock и lock совсем нет никакого интервала ожидания и второй поток просто не успевает "воткнуться". Перенеси "sleep" в другую точку и ты увидишь что все вполне "fair":

Я понимаю, речь больше именно о том сценарии, когда "поток не успевает воткнутся".
Истинно fair мьютексы его поддерживают.

Свой тред удалил, потому что коллеги сказали, что велосипед, который я сделал, сделан уже в одной библиотеке, поэтому я успокоился насчёт его корерктности.

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

AG>Свой тред удалил, потому что коллеги сказали, что велосипед, который я сделал, сделан уже в одной библиотеке, поэтому я успокоился насчёт его корерктности.

Вот это зря, имхо. Другим же тоже интересно.

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

R>Вот это зря, имхо. Другим же тоже интересно.

Ну вот тогда исходный вопрос, кому интересно:

http://rsdn.org/forum/trash/7640671.1

Ещё к сведению, другие примеры fair мьютекса — это мьютекс Windows, который CreateMutex, и в старых версиях Windows таковой была критическая секция.

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

AG>Ну вот тогда исходный вопрос, кому интересно:
AG>http://rsdn.org/forum/trash/7640671.1

Меня несколько смущает, что такое использование очереди "выстраивает" работу потоков в строгой последовательности. Как-то это не очень привычно для fair многопоточности Да и приоритеты потоков при этом никак не учитываются.

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

AG>http://rsdn.org/forum/trash/7640671.1

AG>Ещё к сведению, другие примеры fair мьютекса — это мьютекс Windows, который CreateMutex, и в старых версиях Windows таковой была критическая секция.

Например классический Ticket Lock

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

R>Меня несколько смущает, что такое использование очереди "выстраивает" работу потоков в строгой последовательности. Как-то это не очень привычно для fair многопоточности Да и приоритеты потоков при этом никак не учитываются.

В принципе, приоритеты можно решить перестановкой в очереди.
Добавив в эту перестановку некоторый элемент случайности, можно обеспечить, чтобы потоки с низким приоритетом всё же иногда получали управление.
И заодно сломать "строгую последовательность".

В целом в плане перформанса такие мьютексы не очень из-за лишних переключений контекста.
Но зато позволяют не допустить голодание (starvation).

У меня именно тот случай, когда борьба с голоданием важна, а потеря перформанса не ощущается.

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


AG>Ещё к сведению, другие примеры fair мьютекса — это мьютекс Windows, который CreateMutex, и в старых версиях Windows таковой была критическая секция.

sleep нужно делать после разлачивания мьютекса. Причём, достаточно sleep(0), чтобы передать управление другим потокам. Тогда конкуренция будет гарантировано конкурентной.

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

M>Здравствуйте, Alexander G, Вы писали:


AG>>Ещё к сведению, другие примеры fair мьютекса — это мьютекс Windows, который CreateMutex, и в старых версиях Windows таковой была критическая секция.

M>sleep нужно делать после разлачивания мьютекса. Причём, достаточно sleep(0), чтобы передать управление другим потокам. Тогда конкуренция будет гарантировано конкурентной.

На всякий случай "воткнусь" с комментарием, что если идёт постоянная конкуренция за взятие мьютекса, то надо садитсья и обдумывать ситуацию. Ибо что со sleep(), что без него будет ресурсное голодание с крайне низким throughput, просто с разными последствиями ("один поток лопает от пуза, остальные ждут" vs "все стоят в очереди за очередной корочкой хлеба").

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

MD>На всякий случай "воткнусь" с комментарием, что если идёт постоянная конкуренция за взятие мьютекса, то надо садитсья и обдумывать ситуацию. Ибо что со sleep(), что без него будет ресурсное голодание с крайне низким throughput, просто с разными последствиями ("один поток лопает от пуза, остальные ждут" vs "все стоят в очереди за очередной корочкой хлеба").

В общем, провёл эксперимент на десяти потоках с циклом в 10 повторов. Если Sleep(0) или std::this_thread::yield(), который внутри тот же Sleep(0), делать за пределами захвата мьютекса, то ничем лучше не становится. Если хотя бы 1 мс, то всё отлично.

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


MD>На всякий случай "воткнусь" с комментарием, что если идёт постоянная конкуренция за взятие мьютекса, то надо садитсья и обдумывать ситуацию. Ибо что со sleep(), что без него будет ресурсное голодание с крайне низким throughput, просто с разными последствиями ("один поток лопает от пуза, остальные ждут" vs "все стоят в очереди за очередной корочкой хлеба").

Ситуация "все стоят в очереди за очередной корочкой хлеба" меня устраивает.

В моём случае эти все — собственно рабочий тред, работа которого ограничена перформансом некоей железки, и периодический поллинг статуса железки для прорисовки его на UI.
Ограниченный throughput железки принимается как известное ограничение.
Ради редкого поллинга статуса готов чутка тормознуть рабочий тред.

Совмещать весь поллинг в один тред тоже неудобно. Поллинг никак не связанн с рабочим потоком, поэтому совмещение выглядит странным, там более, что рабочих много разных сортов.

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

M>В общем, провёл эксперимент на десяти потоках с циклом в 10 повторов. Если Sleep(0) или std::this_thread::yield(), который внутри тот же Sleep(0), делать за пределами захвата мьютекса, то ничем лучше не становится. Если хотя бы 1 мс, то всё отлично.

Просто взять и воткнуть sleep — совсем плохо.

Оно будет убивать перформанс всегда, даже если за мьютекс нет борьбы. Ну с этим, допустим, можно бороться, ведя учёт ждущих.

Далее, sleep не даёт преимуществ другому ждуну, в нагруженой системе результат будет менее предсказуемый.

Конкретно Sleep(1) на каждый захват уже неприемлемо просадит перформанс в моём случае, код под мьютексом в реале выполняется быстрее одной миллисекунды.

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

AG>В моём случае эти все — собственно рабочий тред, работа которого ограничена перформансом некоей железки, и периодический поллинг статуса железки для прорисовки его на UI.

Если мьютекс для прорисовки UI, то однозначно прорисовкой заниматься должен один поток, а задания на прорисовку ему в очередь могут складывать все, кому это требуется. Тогда мьютекс только для очереди. Точнее, там лучше примитив синхронизации "монитор" (conditional variable + mutex)