Синхронизация потоков через БД

← →
[ВладОшин] © (2013-11-13 14:35) [0]

Что подумал - если ПО работает в БД, то почему бы и нет?
Сейчас уже есть ~ 15 потоков, и планируется только их добавление.
Так пуркуа бы и не па?

из ++
Ничего напутать невозможно в принципе. Запись в БД - атомарна, по-любому.

← →
[ВладОшин] © (2013-11-13 14:37) [1]

табличка, типа T_applic_name_setup
и два поля
(id)
NameVar varchar,
ToStringVar varchar

← →
[ВладОшин] © (2013-11-13 15:11) [2]

Хрень какая-то, да?
Или нет?

← →
megavoid © (2013-11-13 15:55) [3]

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

← →
Ega23 © (2013-11-13 16:00) [4]

> Запись в БД - атомарна, по-любому.

В рамках транзакции. Если чё.

← →
Ega23 © (2013-11-13 16:04) [5]

Что-то я немного не понял.
Вот два потока. Один, например, что-то пишет. Другой - что-то читает. Читать должен строго после того, как первый закончил писать, так что-ли?

← →
Плохиш © (2013-11-13 16:06) [6]

> Хрень какая-то, да?

Да

← →
megavoid © (2013-11-13 16:09) [7]

> Вот два потока. Один, например, что-то пишет. Другой - что-
> то читает. Читать должен строго после того, как первый закончил
> писать, так что-ли?

Типа того, например, rss-собиралка новостей: два процесса по крону ("потока"), один ходит по списку rss и инсертит их, второй, по более частому крону, делает select where parsed=false, парсит, делает полезную работу, помечает parsed=true. Халявная "синхронизация" за счёт базы, все довольны :)

← →
Ega23 © (2013-11-13 16:14) [8]

> Типа того

А если "типа того", то как тогда ставить этот поток в ожидание? Ну аналог крит.секции?

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

← →
[ВладОшин] © (2013-11-13 16:30) [9]

> . Читать должен строго после того, как первый закончил писать,
> так что-ли?

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

там либо целиком старое, либо новое будет
никогда не будет посредине (естественно в одной транзакции)

← →
Ega23 © (2013-11-13 16:43) [10]

> там либо целиком старое, либо новое будет

А нафига тогда? У тебя готовый механизм транзакций есть, это и есть твоя "синхронизация".

> У тебя готовый механизм транзакций есть, это и есть твоя
> "синхронизация".

наверное, ответ очевиден
(внимание!) "да"

т.е. к чему - не надо защищать критикал секшн, проч.
с возможностью напутать
Надо зарегить переменную в список синхронизаций, и писать(умно, если только изменилось)/читать список

> Плохиш © (13.11.13 16:06) [6]
>
>
> > Хрень какая-то, да?
>
> Да

первая реакция была такая же (когда спросил сам себя)
но если не важна скорость(+еще что-то) - это же гарантированнейший способ. Монстры от IT ручаются.

> megavoid © (13.11.13 15:55) [3]

не только там

у потока есть ряд общих переменных
сначала он их регистрирует
RegisterVar(SomeVar1)
RegisterVar(SomeVar21)
RegisterVar(SomeVarN)

По адресу переменной некая процедура понимает, что именно регистрируется

Потом поток[i] говорит
Change([
var1, 12,
var2, "вася",
varN, now,
)
и все это одним действием происходит

в это время любой может сказать GetVar([var1,var2]) - и ему будет
или 12, "Вася"
или что угодно другое1, что угодно другое2
но никогда
не что угодно1, Вася

http://www.lib.ru/LITRA/CHEHOW/r_letter.txt

Читать

Почитал. Вспомнился философ. Эх... Хотя нет - он грамотно писал.

Синхронизация потоков через БД Найти похожие ветки