Сложная синхронизация Опции

[lanz]

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

Мы о разных вещах говорим, то что тред использующий мьютекс засыпает, возможно только при наличии ОС. К самой идее мьютекса это не относится.
Например QMutex использует события под виндой и pthread_mutex_t под лин. Но при этом и тот и тот вроде как мьютекс.

Это я к тому, что вопрос в том как не использовать мьютексы неверен. Правильно спросить - как реализовать синхронизацию, не используя системный-объект-мьютекс или другие системные объекты.
На этот счет есть например такие ссылки
http://en.wikipedia.org/wiki/Dekker%27s_algorithm
http://en.wikipedia.org/wiki/Peterson%27s_algorithm
http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
http://en.wikipedia.org/wiki/Szymanski%27s_Algorithm
Все они так или иначе полагаются на атомарные операции, которые реализаванны через семейство QAtomic, который позволяет использовать всевозможные барьеры кроссплатформенно.
Про барьеры можно почитать тут:
http://www.rdrop.com/users/paulmck/scalabi...2010.07.23a.pdf

Сообщение отредактировал lanz - 14.1.2015, 19:59

[lanz]

Наврал немного, QMutex под лин использует
https://ru.wikipedia.org/wiki/Фьютекс
Опять наврал.
Век живи, век учись

Сообщение отредактировал lanz - 14.1.2015, 21:17

[Iron Bug]

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

[lanz]

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

Какие суровые грабли?
Разницы между мьютексами и спинлоками относительно дедлоков нет никакой. То что тред засыпает никак не спасет от дедлоков, если они возможны.
А если мьютекс гибридный?

Вот дедлок с мьютексами:

mutex A;
mutex B;

A:
{
  lock A;
  wait 3000;
  lock B;
  unlock B;
  unlock A;
}

B:
{
  lock B;
  wait 1000;
  lock A;
  unlock A;
  unlock B;
}

Нет разницы, если бы я заменил слово mutex на spinlock или semaphore.

В продолжение темы про барьеры, относительно конкретно Qt
http://blog.qt.digia.com/blog/2009/10/06/m...ring-semantics/

[Iron Bug]

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

[lanz]

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

Каким образом?

[Iron Bug]

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

Каким образом?

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

[lanz]

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

Не совсем так

Возможно два случая
- когда ОС может переключить тред, который пытается захватить спинлок - тут нет никаких проблем, когда понадобится, тред переключится, спинлок освободится
- ОС не может переключить тред - если ОС не может преключить тред, тогда любой вечный цикл, спинлок или нет, завешивает всю систему, с этим как бы никто и не спорит

http://www.makelinux.net/ldd3/chp-5-sect-5

If a nonpreemptive uniprocessor system ever went into a spin on a lock, it would spin forever; no other thread would ever be able to obtain the CPU to release the lock.

For this reason, spinlock operations on uniprocessor systems without preemption enabled are optimized to do nothing, with the exception of the ones that change the IRQ masking status.

(барабанная дробь)

The kernel preemption case is handled by the spinlock code itself. Any time kernel code holds a spinlock, preemption is disabled on the relevant processor.

То есть если я пишу в режиме ядра под Linux и использую spinlock_t, то процессор зависнет, если я попытаюсь захватить один и тот же спинлок два раза на одном процессоре.
Вот это интересно, и про это могли бы и рассказать, раз уж обмолвились

[Iron Bug]

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

[lanz]

fence ничего не блокирует, он просто запрещает перестановку различных операций на процессоре.

Вот например код mutex_lock в ядре использует спинлок:
http://www.cs.fsu.edu/~baker/devices/lxr/h...el/mutex.c#L207