Re:Concurrency I can finally understand and write correctly
by pjmlp on Monday March 12, 2018 @05:57PM
(#16572055)
In a way it is ironic that we went full speed into threads, shared memory and plugins, only to go back into processes, messages and sandboxing as a means to tame multi-core programming and safety.
Re:Concurrency I can finally understand and write correctly
by zokier on Monday March 12, 2018 @07:08PM
(#16572508)
I thought threads and shared memory were introduced more as performance hacks than superior architecture. It is not surprising that as the performance profile has changed (due both increased core counts and improved software primitives), we are getting back those things that were deemed too expensive previously
Re:Concurrency I can finally understand and write correctly
by platz on Tuesday March 13, 2018 @02:19AM
(#16574163)
Concurrency abstractions are still built on primitives that involve locks and memory barriers.
Re:Concurrency I can finally understand and write correctly
by pjmlp on Tuesday March 13, 2018 @03:43AM
(#16574391)
Just like the old UNIX process IPC or micro-kernels communication is.
Re:Concurrency I can finally understand and write correctly
by sametmax on Monday March 12, 2018 @09:30PM
(#16573238)
But don't we have thread pools and futures for that ? You can't get a simpler API.
Re:Concurrency I can finally understand and write correctly
by amarkov on Tuesday March 13, 2018 @05:42AM
(#16574783)
Futures aren't a natural way to formulate many important concurrency problems. If I want a thread polling an external system and putting records in a work queue for as long as my application is running... well, what's that a future of?
Re:Concurrency I can finally understand and write correctly
by sametmax on Tuesday March 13, 2018 @11:45AM
(#16577063)
That's what thread pools are for. They have a work queue you fill and workers depop it. Literally 5 lines in python and i imagine most modern languages.
Re:Concurrency I can finally understand and write correctly
by amarkov on Tuesday March 13, 2018 @12:13PM
(#16577269)
Right, but thread pools are simple because they don't offer any sort of API for the tasks in the work queue. You're just writing arbitrary code. So rather than reasoning about an abstract execution model, you have to carefully think about every line to make sure you don't accidentally share mutable state.
Re:Concurrency I can finally understand and write correctly
by therealdrag0 on Tuesday March 13, 2018 @01:39PM
(#16577980)
In Java with Spring you'd do something like:
@Scheduled(fixedRate = 5000) public void poll() { getCrapAndPutOnConsumerQueue(); }
I have worked with Java, C# and Python, and for each I have developed a concurrent object framework, making it quite easy to work with multible channels of incoming events, for example for process control systems with barcode-scanners, scales, I/O-busses etc. connected to the system
I think ponylang does a pretty good implementation of the Actor model.
Feel free to have a look at the Python impl. of the framework (www.github.com/pylots/pyworks)