Hi Ben, On Apr 18, 2015, at 10:57 AM, Ben Coman <btc@openInWorld.com> wrote:
On 18/04/2015 3:36 pm, "Esteban Lorenzano" <estebanlm@gmail.com> wrote:
So⦠âmultithreadâ is a complicated issue. Pharo as most Smalltalks is designed thinking is as monolithic so if you are trying to make the image to work in different processes⦠it will not be easy at all :)
The goal here is very different. The goal is not to build a multithreaded Smalltalk such that multiple processes execute concurrently on multiple cores or processors. The goal is instead to allow the system to interact freely with multiple threads through the FFI. The scheme allows any number of threads to run the VM but only one if them is running the system at any one time. The scheme allows the VM to change thread on any FFI call, process switch or callback. It makes it extremely cheap to release the VM on a callout so that every FFI call, even one to something trivial such as strlen, to be a release point. On callout the thread performing the FFI call reads the value of the owningThreadID variable, zeros the variable and makes the callout. When that thread returns from the FFI call it tries to conditionally set owningThreadID to its id if it is zero, but if it is non-zero, and therefore owned by some other thread, enters a wait state where the scheduler will give it back the VM at the next suitable opportunity. The heartbeat checks for owningThreadID being zero, and if so, either an existing thread that is waiting, or a new thread if none are waiting, is scheduled and tries to own the VM by again attempting to conditionally set owningThreadID to its ID. Processes can be bound to threads so that the system respects priorities and allows certain activities to happen on specific threads. Callbacks from as-yet-unknown processes can be accepted. The scheme, David Simmons' from his Smalltalk VMs, is relatively simple and extremely efficient. But it's still non-trivial to develop and needs effort to realize. My prototype hasn't been worked on for four years. It is rusty. But it'll work and work well.
The holy grail of multithreaded seems to be functional programing, where essentially the benefit comes from threads not modifying global state. The problem with our monolithic system is that you are often (if not always) modifying global state. Worker threads can be written that avoid explicitly modifying global state, but your worker call a method that calls a method that calls a method that unnoticed by you modifies global state. This has been the source of a number of bugs I've hunted down in Pharo (e.g. Transcript; Monticello repository filter). You have to dig deep to notice these and I have wondered if somehow there could be some system help to make such cases fail-early such that any assignment to any instance variable generates an exception. You could turn this on for worker threads to ensure they can't inadvertently affect the monolithic assumptions of the main system.
Of course the worker threads need to deal with transient global state, but you are in control writing new code with this in mind -- but it protects reuse of existing monolithic code.
What would it take to get such a feature?
Cheers -ben