Криптокомбинятина небеснаяВах:
http://en.wikipedia.org/wiki/Read-copy-update ...writes to single aligned pointers are atomic on modern CPUs, allowing atomic insertion, removal, and replacement of data items in a linked structure without disrupting readers.

эт че, транзационная память на аппаратном уровне?

з.ы. на программном в хаскеле хорошо реализована.
а так, еще в кложуре видел.

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

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

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

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

Криптокомбинятина небеснаяZyK_BotaNпропущено...


эт че, транзационная память на аппаратном уровне?

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

А указатель в C++ - это оно и есть. Те самые 4 или 8 байт (32 bit, 64 bit). Если указатели записывать в память по выровненным адресам, изменяться они будут атомарно.

P.S.
Я тут один алгоритм реализовывал. Выравнивание и последовательный доступ к памяти дали прирост процентов 40 по производительности перед случайным доступом (раньше 0.4 сек, после выравниваний и изменения схемы доступа - 0.2 сек).
а ты уверен, что это не что-то вроде STM?

я тогда пойду погуглю.

ZyK_BotaN
а ты уверен, что это не что-то вроде STM?

я тогда пойду погуглю.[/quote]а да. я все перепутал. это совсем другое.
здесь как раз локи есть.

Криптокомбинятина небеснаяZyK_BotaNмне такой подход - больше чем локи нравится.
здесь не может быть дедлоков(если ошибаюсь - покажите юзкейс, когда дэдлок будет)
но и накладные расходы здесь большие, что не очень гуд.
Такой - это RCU? Наоборот - нулевый расходы в реальной линуксовой реализации, например (из википедии). От дедлоков защищена "по определению".да я спутал с STM.
думал что это что-то похожее.

Криптокомбинятина небеснаяОт дедлоков защищена "по определению".
хм?
опиши как?
от дедлоков защищена STM, потому, что там совсем локов нет.

а в RCU - локи есть?

авторOne thing that disappoints me personally about all of these mechanisms is their limited support for RCU. Don't get me wrong, you can use RCU with HTM updates. However, bare RCU readers will typically cause HTM updaters to unconditionally abort. Although RCU's purpose is in fact to favor readers, this is entirely too much of a good thing. For ideas for improved interactions between TM and RCU, please see an earlier posting. It is also unclear to what extent HTM helps in cases involving severe real-time-response constraints.

There have also been some interesting software transactional memory (STM) papers. Pankratius and Adl-Tabatabai published a productivity comparison in which the highest productivity was attained by teams that used both STM and locking. Although one can argue that inevitable transactions will subsume the uses of locking in the Pankratius paper, inevitable transactions are normally implemented as a global lock. sharply limiting I/O scalability.

http://paulmck.livejournal.com/31285.html

Криптокомбинятина небеснаяНу разочаровывает это чувака по каким-то параметрам, дальше-то что?ниче. просто про RCU первый раз слышу, вот мне и интересны недостатки\преимущества по сравнению с STM.