Что не так с Futex?

Question

[MuffinLover]

https://gist.github.com/stepan-neretin7/225d8753ef...
Error: Attempting to unlock a mutex not owned by the calling thread.
Ума не приложу почему такая ошибка со своим mutex
подскажите, пожалуйста
никак не получается отловить почему

Answer 1

[jcmvbkbc]

почему такая ошибка со своим mutex

потому что pthread_t шире чем int owner, и как следствие этот тест не работает.

Comments

[MuffinLover]

Изменил gist, поменял все та же ошибка
Error: Attempting to unlock a mutex not owned by the calling thread.
Total: 0 asc: 0 dsc: 0 eq: 0

[jcmvbkbc]

MuffinLover, не то ты изменил. Надо было менять int owner, по нормальному -- на pthread_t owner.

[MuffinLover]

jcmvbkbc, да действительно
а почему asc, desc - 0 все равно
с обычными mutex все ок было
https://pastebin.com/c3bZqt43

[jcmvbkbc]

MuffinLover, потому что у тебя все строки в списке пустые, потому что ты никуда их не записываешь при создании списка.

[res2001]

Еще и гонка внутри мьютекса за owner и count, т.к. они никак не защищены, не синхронизируются и даже не volatile.

[jcmvbkbc]

res2001, я не вижу гонки, но вижу сомнительное обращение к owner вот здесь. Как минимум там нужен барьер, парный к этому барьеру. В других местах на мой взгляд всё ок. count и owner меняются только владельцем мьютекса под защитой lock, который меняется атомарно.

[res2001]

jcmvbkbc, Ну да тут гонка на чтении, аналогично и в unlock(). Нужен барьер или атомарные операции.
Вероятно не правильное срабатывание (или не срабатывание) условия.
Отсюда и появление ошибки.

[jcmvbkbc]

тут гонка на чтении

res2001, объясни, кто с кем гоняется, я не вижу гонки. Условие здесь может быть истинным только в потоке-владельце, владелец может менять count как хочет, потому что другие потоки к нему не обращаются. Более того, если поток освободит мьютекс, а потом захочет захватить его обратно будучи на том же процессоре, он гарантированно увидит, что он не является владельцем. Вот чтобы гарантировать, что он увидит, что он не является владельцем будучи на другом процессоре нужен барьер чтения перед этой проверкой. Ну и аналогично, когда вледелец мьютекса только что захвативший его на одном CPU мигрирует на другой CPU и захватывает его повторно тот же самый барьер гарантирует, что условие проверки владения сработает правильно.

Нужен барьер или атомарные операции.

Для чего тут атомарные операции?

Отсюда и появление ошибки.

Появление ошибки -- из-за неправильно написанного кода. Обе упомянутые ошибки 100% детерминированные и воспроизводятся с одним потоком.

[res2001]

jcmvbkbc,

объясни, кто с кем гоняется, я не вижу гонки.

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

Можешь не называть это гонкой, я не знаю другого подходящего термина.

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

Для чего тут атомарные операции?

Атомарные операции - т.к. они включают в себя барьер. Или барьер или атомарные операции c owner.

Кстати, ошибка

Total: 0 asc: 0 dsc: 0 eq: 0

возможно говорит о том, что кастомный мьютекс не обеспечивает барьер памяти. А должен.
Хотя у него там сгенерированная строка не копируется в узел списка, поэтому все манипуляции со списком происходят на пустых узлах без данных. Но хотя бы Total и eq расти должны.

Обе упомянутые ошибки 100% детерминированные и воспроизводятся с одним потоком.

Этот код не запускал, т.к. сейчас на винде сижу, а у него тут фьютексы. Но запускал предыдущую версию с нормальными pthread мьютексами - все работало.

[jcmvbkbc]

Total: 0 asc: 0 dsc: 0 eq: 0
возможно говорит о том, что кастомный мьютекс не обеспечивает барьер памяти.

res2001, да не, это говорит о том, что поток монитора успел сделать проход по списку до всех остальных потоков.

[res2001]

jcmvbkbc, он же там крутится в вечном цикле, а счетчики не меняются

[jcmvbkbc]

res2001, первые несколько циклов -- не меняются, дальше -- меняются.