Атомарность операций над стандартными типами C++

[PredatorAlpha]

Там используется то, что деструкторы локальных объектов вызываются в любом случае, даже если return где-то в теле или возникло исключение. Очень удобная штука для освобождения ресурсов.
Просто Ochkarik больше на классическом С работает...

[Ochkarik]

а в каком месте та переменная то стоит, которую синхронизировать надо было?

[RuNTiME]

Ochkarik, Тут просто пояснение почему и как работает MutexLocker. Переменную смотри в начале, где я выкладывал код класса Thread.

[Ochkarik]

я просто за основной алгоритм принял фразу:
"Есть переменная, тип int. Два потока пишут в эту переменную, а третий считывает значение этой переменной."
и для этого - функции ожидания не нужны.

а на самом деле, вам еще и функции ожидания была жизненно необходима?

Просто Ochkarik больше на классическом С работает...

есть немного))))

[PredatorAlpha]

Просто Ochkarik больше на классическом С работает...

есть немного))))

Я сам такой...
Embedded-программер..

[RuNTiME]

Ochkarik,

а на самом деле, вам еще и функции ожидания была жизненно необходима?

Изначально мне нужно было только лишь узнать, можно ли безопасно считывать значение этой самой переменной. И я сформулировал только суть. Ну, а раз уж тему развили, почему бы и не по обсуждать связанные с этим проблемы...

[Ochkarik]

тады - ой)

[Антон (LogRus)]

ну и очередные мои 5 копеек
lock не блокирует шину, времена те давно минули
lock блокирует кэш линию

пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят
обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах

PS: а зачем тебе своя реализация всего этого чуда, если есть открытые и быстрые?
PPS: а сравнительные тесты будут?
PPPS: кстати рекомендую использовать названия для классов и методов используемые в tbb и boost::thread - это позволит быстро менять реализацию блокировок в приложении или отдельном классе в зависимости от желания и модели использования конкретного класса

[darkelf]

пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят
обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах

Прошу прощения, но, imho, asm к mutex-ам/futex-ам имеет опосредованное значение, и, насколько я помню, futex-ом называется один из базовых примитивов синхронизации в linux, который был реализован при переходе с Linuxthreads на NPTL. Кроме того, определённый объект ядра там используется - очередь ожидания, иначе как ядро обеспечит ожидание нескольких потоков (По крайней мере так написано в документе The Native POSIX Thread Library for Linux).

[Антон (LogRus)]

darkelf, что-то я про это совсем забыл вот я раздолбай, давно много потоковые системы не строил

[RXL]

пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят
обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах

Собственно, расположив их в разделяемой памяти можно и межпроцессное взаимодействие осуществлять без участия ядра.


Добавлено через 2 минуты и 45 секунд:
darkelf, принцип простой: если не можешь захватить, то выполни yield() и потом еще раз попробуешь. Никаких дополнительных очередей - все в рамках обычного планировщика.

[RuNTiME]

PS: а зачем тебе своя реализация всего этого чуда, если есть открытые и быстрые?

По двум причинам:
Первая и основная углубленное изучение многопоточного программирования (ну хочется мне).
А вторая банальная - свести к минимуму кол-во зависимостей.

PPS: а сравнительные тесты будут?

Сравнивать пока нечего да и основные задачи библиотеки не реализация классов для написания многопоточных приложений.

PPPS: кстати рекомендую использовать названия для классов и методов используемые в tbb и boost::thread - это позволит быстро менять реализацию блокировок в приложении или отдельном классе в зависимости от желания и модели использования конкретного класса

За наводку на tbb спасибо. Вчера еще скачал эту библиотеку. Будет с чего брать пример.
boost - очень уж громоздок если использовать его только для запуска потоков

[darkelf]

Добавлено через 2 минуты и 45 секунд:
darkelf, принцип простой: если не можешь захватить, то выполни yield() и потом еще раз попробуешь. Никаких дополнительных очередей - все в рамках обычного планировщика.

Imho, yield(), требует как входа в ядро, так и использования очереди - в случае, если есть более высокоприоритетные процессы/потоки текущий процесс надо будет приостановить, соответственно, поставить в очередь ожидания и выполнить переключение контекста на более приоритетный.

[Ochkarik]

RuNTiME, может вы целиком задачу опишите, а то разговор пошел на пустом месте)
задач много, способов реализации тоже) щас каждый выложит свои задачи многопоточности и соответствующие решения и будет каша)

[RXL]

darkelf, для проверки и захвата мютекса входить в ядро не нужно - это и есть преимущество. А вот в случае неудачи захвата по любому придется ожидать.

[darkelf]

darkelf, для проверки и захвата мютекса входить в ядро не нужно - это и есть преимущество.

Про это я знаю.

А вот в случае неудачи захвата по любому придется ожидать.

В принципе, я про это и говорил, видимо мы друг-друга немного не поняли.

[RuNTiME]

Ochkarik, На вопрос для которого создавалась эта тема я получил ответ, получил даже намного больше. Общая задача это написание библиотеки сильно упрощающей разработку Web приложений на C++. Это не производственная задача, пишу в своё удовольствие (так что сильно не пинайте).   Если кому - то это интересно, могу создать отдельную тему и можем обсудить целесообразность всего этого.