LINUX.ORG.RU
Форум — Development  

многопоточность и mutex


0

0

Тут возникла такая проблема (С++, gcc, linux) с многопоточность.

Есть несколько потоков которые работают с общим списком структур, в
каждый из потоков передаётся указатель на этот список.

Для блокировки использую переменную типа int, что то вроде int lock. И
при попытке обратиться к списку я проверяю состояние этой переменной

примерно так

while(1) if(base_object->lock == 0) break;

где base_object указатель на объект класса в котором и создаются потоки.

Вопрос такой, такое использование аналогично использованию mutex'ов или
они (mutex) буду по другому себя вести. Проблемма собственно в том что
в моём варианте, _КАК_МНЕ_КАЖЕТСЯ_, потоки успевают одновременно писать
в список...на знаю правда, как они умудряются проскочить проверку флага
lock.

Заранее спасибо!

★★★★★

>как они умудряются

"Одновременно" проверяют условие, потом одновременно делают lock=1.

Используй мутексы.

Davidov ★★★★
()

> на знаю правда, как они умудряются проскочить проверку флага lock.

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

Не утверждаю, что у тебя именно так.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Davidov

+1

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

svu ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Ну а volatile всё-равно не решает проблемы. Переключение задач может произойти в любой момент времени.

Begemoth ★★★★★
()

Можно еще использовать атомарные операции с интами(сравнение + присвоение). Если работа с захваченным объектом идет не долго(e.g. до тысяч инструкций) - такой вариант думаю будет нормально работать в смысле скорости.

YesSSS ★★★
()
Ответ на: комментарий от cyclon

Собственно, мьютексы чаще всего и являются целочисленными элементами. Всё дело в операциях захвата и освобождения. Для мьютексов они атомарны (т.е. потокобезопасны). Такие дела.

env ★★☆
()

По исходному посту - автор сделал, по сути, spinlock, но забыл про атомарные операции, memory barriers и compiler barriers, поэтому эта штука работать не должна.

erDiZz ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development