вообще действительно непонятно. Неужели к synchronized классу надо еще какой-нибудь mutex?

Так это и есть обвертка над мютексом

так я вот и думаю

так да, synchronized нормально работает с обычными типами, хотя даже для сложения нужно делать вот так test.atomicOp!"+="(4);

и вот такого же аналога для insertFront нету, я так понимаю

делаю вот так synchronized class SocksQueue{ private DList!string _queue; public void push(string data) { _queue.insertFront(data); } public string pop() { auto res = _queue.back(); _queue.removeBack(); return res; } }

https://tour.dlang.org/tour/en/multithreading/synchronization-sharing я много раз смотрел ссылку, но не обращал внимания на примеры кода справа, а там прямо таки класс SafeQueue описан и прочие отличные вещи)

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

через message passing может быть race conditions

?

ну вроде нет гонок

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

через message passing может быть race conditions

а что это такое? message passing

Есть два подхода обмена данными. Lock data и message passing. То что вы хотите - Lock data. Message passing когда передаются данные по каналам.

Сейчас пример дам

https://tour.dlang.org/tour/en/multithreading/message-passing

Ну такой себе подход. Тред же при этом блокируется

И.к. функция ресив блокирующая

Я предпочитаю пейр сокет

Это может позволить общаться с любым тредом и не блокировать его

https://tour.dlang.org/tour/en/multithreading/message-passing

посмотрю, спасибо

Ну такой себе подход. Тред же при этом блокируется

Не блокируется. Проверьте

Да ладно!

Блокирующая

Сейчас тест напишу

module test; import std.stdio; import std.concurrency; import core.thread; // ... void main() { auto worker = spawn(&workerFunc); worker.send(1); Thread.sleep(3.seconds); worker.send(2); Thread.sleep(3.seconds); worker.send(0); } void workerFunc() { bool end = false; while (!end) { writeln("tick"); receive(delegate(int t){ writeln(t); if (t == 0){ writeln("end"); end = true; } }); } }

Если бы функция receive была бы не блокирующей, мы бы ОЧЕНЬ много раз видели бы в логах строку "tick"

Но мы видем ее только тогда, когда отсылаем сообщение потоку

Так что эта функция блокирующая

Что не позволяет использовать новый поток как полноценный независимый поток обработки данных

А получаем поток, который ждет указаний на выполнение.

Конечно, иногда это очень даже подходит

Если делаешь что-то типа своих куратин

В зависимости от полученных данных - выполняешь какие-то действия

НО! Ответ от этого потока мы можем получить тоже только блокирующи

Соответственно для подобных вещей он не сильно то уж и подходит

А вот пейрСокет - открываешь их, а после стартуешь поток. Первый сокет в родителе, второй в дочернем потоке

И реализуешь IPC через него

Хочешь - гоняй данные даже через него

Но легче сделать для этого или шейред память

Или просто __gshared переменную

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

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

Годно

После пихаешь этот сокет в общий луп

И все...

@devBocharov покури эти советы. Завтра попробуем на деле :)

что-то я не понял видимо о чем речь. Да, receive вперед другой receive не побежит, но другие потоки останавливать не станет

но это как раз то, что надо

в потоках делаешь что-то с объектом, а в receive кладешь его в контейнер

Ну смотри

Это приведет к тому, что ты, скажем, не сможешь обрабатывать в этом потоке входные соединения

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

Но как дать родительскому потоку знать о том, что он доделал работу???

Честно сказать, не могу понять о чем речь. Есть вот еще какой вариант https://run.dlang.io/gist/3afff560fe3b2f439272c3ee3adcebd0?compiler=dmd можно избавиться от shared через cast. А гарантию того, что данные будут меняться только в одном потоке вы даете через syncronized класса и приватность этого поля

Но как дать родительскому потоку знать о том, что он доделал работу???

кстати можно также передать сообщение

или атомарный флаг

или атомарный флаг

это про что Вы?

про то же

Но как дать родительскому потоку знать о том, что он доделал работу???

^

В начале faq на сайте выглядел холиваристо, теперь это просто толстый тролинг, разочерование

Честно сказать, не могу понять о чем речь. Есть вот еще какой вариант https://run.dlang.io/gist/3afff560fe3b2f439272c3ee3adcebd0?compiler=dmd можно избавиться от shared через cast. А гарантию того, что данные будут меняться только в одном потоке вы даете через syncronized класса и приватность этого поля

Синхронизация - это обвертка над мютексом

Зачем?

Можно вообще без него писать, если его гарантированно его меняет только один поток

кстати можно также передать сообщение

Можно, но это нужно ещё сериализацию писать, а на это уйдет память и время

А так у тебя уже есть этот объект в памяти

ERROR: S client not available

кстати можно также передать сообщение

Немного не так понял Ваше сообщение сначало. Конечно можно, но при этом родительский тред будет заблокирован в ожидании ответа от дочернего.

https://github.com/LLC-CERERIS/big.d/blob/dev/README.md

Но он тоже базируется на vibe...

@devBocharov https://forum.dlang.org/post/mailman.921.1509747928.3360.digitalmars-d-learn@puremagic.com

@devBocharov https://forum.dlang.org/post/mailman.921.1509747928.3360.digitalmars-d-learn@puremagic.com

спасибо, т.е. любая работа с shared объектом должна проходить в вот таких synchronized блоках? понятно, а что там за mutexForMySharedObject? shared(DList!string) sharedDlist; Mutex mutexForSharedDlist; void main(){ synchronized(mutexForSharedDlist) { auto queue = cast(DList!string)sharedDlist; queue.insertFront("a"); } } в таком виде ошибку Segmentation fault (core dumped) выдает, а если просто shared(DList!string) sharedDlist; void main(){ synchronized { auto queue = cast(DList!string)sharedDlist; queue.insertFront("a"); } } то норм

> спасибо, т.е. любая работа с shared объектом должна проходить в вот таких synchronized блоках? для избежания гонки данных

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

synchronized просто синхронизирует)

Использует mutex класса

Так же, если используются несколько mutex'ов фиксирует последовательность их захвата: два потока хотят захватывать A и B, но в одном было написано synchronized(A,B), в другом synchronized(B, A) - в обычном языке привело бы к deadlock, в D не будет, так как они будут всегда захватываются в одном порядке вне зависимости от написания в коде

Использует mutex класса

а как его использовать правильно в этому случае? вот так та же ошибка class Queue { private DList!string socksQueue; Mutex mtxQueue; } shared(Queue) sharedQueue; void main(){ synchronized(sharedQueue.mtxQueue) { auto queue = cast(Queue)sharedQueue; } есть такой пример https://dlang.org/phobos/core_sync_mutex.html, но тут без synchronized

а как его использовать правильно в этому случае? вот так та же ошибка class Queue { private DList!string socksQueue; Mutex mtxQueue; } shared(Queue) sharedQueue; void main(){ synchronized(sharedQueue.mtxQueue) { auto queue = cast(Queue)sharedQueue; } есть такой пример https://dlang.org/phobos/core_sync_mutex.html, но тут без synchronized

Тут ты используешь свой mutex, при том, как я понимаю, не создаёшь его (это же класс вроде и нужно его создавать)

я не ссылку вчера отправил

вот правильная https://run.dlang.io/gist/320567145bd5fb985429c6ba28c7ce00?compiler=dmd

Синхронайз - это обвертка над мьютексом

Можете сами это делать

Но те данные, к которым хотите получить доступ - должны быть сшейред

Ну или __gshared

Для тех, кто целеком и полностью понимает, что он делает

вот правильная https://run.dlang.io/gist/320567145bd5fb985429c6ba28c7ce00?compiler=dmd

synchronized class SocksQueue { private DList!string _queue; public void push(string data) { (cast(DList!string) _queue).insertFront(data); } } void main(){ auto s = new shared SocksQueue(); s.push("a"); да, так работает, спасибо еще раз т.е. это правильная реализация такого класса?

протестирую еще, там выше пример видел

Да, потому что мы гарантируем отсутствие гонки данных через synchronized

По идее да

Можешь поставить в начале и конце void push(string data) какой нибудь слип секунд на 5 и посмотреть как в секцию будут входить разные треды.

Можешь поставить в начале и конце void push(string data) какой нибудь слип секунд на 5 и посмотреть как в секцию будут входить разные треды.

ага, понял

И тогда мне интересно, будет ли это работать в случае файберов. Думаю что нет, т.к. файбер не может заблокироваться и ждать освобождения секции, ведь он также остановит все другие файберы в треде.

Для них получается нужен специальный файберный мьютекс?

Можешь поставить в начале и конце void push(string data) какой нибудь слип секунд на 5 и посмотреть как в секцию будут входить разные треды.

synchronized class SocksQueue { private DList!string _queue; public void push(string data) { writeln("push "~data); Thread.sleep(5.seconds); (cast(DList!string) _queue).insertFront(data); } } void main(){ auto queue = new shared SocksQueue(); queue.push("1"); new Thread({ queue.push("2"); }).start(); задержка есть

Круто значит работает )

да, отлично, большое всем спасибо?

Для них получается нужен специальный файберный мьютекс?

Можно просто булеву переменную юзать

типа while(mutex.isLocked) { yield; }?