Hacker News new | ask | show | jobs
by alfanerd 3018 days ago
In my 30+ years experience of concurrency, the shared-nothing message model makes it relative easy to reason about concurrency (since every actor is single threaded).

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)

2 comments

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.
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
Concurrency abstractions are still built on primitives that involve locks and memory barriers.
Just like the old UNIX process IPC or micro-kernels communication is.
But don't we have thread pools and futures for that ? You can't get a simpler API.
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?
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.
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.
In Java with Spring you'd do something like:

@Scheduled(fixedRate = 5000) public void poll() { getCrapAndPutOnConsumerQueue(); }