3 ms·

I've written a lot of multi-threaded code, but I don't think I've written ANY multi-threaded code that doesn't involve queues passing objects (hopefully safely)

by smegel 11y ago

I've written a lot of multi-threaded code, but I don't think I've written ANY multi-threaded code that doesn't involve queues passing objects (hopefully safely) between threads. As in, no locks, no semaphores, no accessing shared state between threads (OK apart from an global flag structure that just set various error conditions encountered and was only interacted with by atomic get/set operations and where order of access was never important). Adding a lock to a program is like a huge red flag - stop everything and really think about what you are doing.

deleted 11y ago
[deleted]
Matthias247 11y ago
Totally agree. I also have written a lot of multithreaded code in the past years. At the beginning I really used locks and acted on various resources from multiple threads. It turned out to get into an unmaintainable mess where you have to think about dozens of invariants before each change. In the meantime I mostly implement things in a way that each data is owned by exactly on thread (or mostly event loops running on a thread or also in a thread pool) and provide thread-safe APIs on top of that by using queues and message (or function object) passing to exchange data and results between the calling thread and the resource-owning thread.
JoeAltmaier 11y ago
Some ivory tower nut proved in the 70s that semaphore-and-thread was logically equivalent to queue-and-message, i.e. the same results could be obtained by each. But queue-and-message is superior in very many ways. Done carefully, you have only the queue as a shared structure. If message processors are non-blocking then the entire system is non-blocking. Deadlock can be statically determined by examination of the message vectors. And last but certainly not least, in the debugger, all important state is in the message or local variables in a message processor. No enormous stacks to dive through, trying to find who did what to whom. Simple single-threaded message processors have straightforward logic. And a message-aware operating system can make the work queues transparent.

by smegel 11y ago

deleted 11y ago

[deleted]

Matthias247 11y ago

Totally agree. I also have written a lot of multithreaded code in the past years. At the beginning I really used locks and acted on various resources from multiple threads. It turned out to get into an unmaintainable mess where you have to think about dozens of invariants before each change. In the meantime I mostly implement things in a way that each data is owned by exactly on thread (or mostly event loops running on a thread or also in a thread pool) and provide thread-safe APIs on top of that by using queues and message (or function object) passing to exchange data and results between the calling thread and the resource-owning thread.

JoeAltmaier 11y ago

Some ivory tower nut proved in the 70s that semaphore-and-thread was logically equivalent to queue-and-message, i.e. the same results could be obtained by each. But queue-and-message is superior in very many ways. Done carefully, you have only the queue as a shared structure. If message processors are non-blocking then the entire system is non-blocking. Deadlock can be statically determined by examination of the message vectors. And last but certainly not least, in the debugger, all important state is in the message or local variables in a message processor. No enormous stacks to dive through, trying to find who did what to whom. Simple single-threaded message processors have straightforward logic. And a message-aware operating system can make the work queues transparent.