NativeBoost / Callbacks and Multithreading
Hi, I've tried to build a pharovm with multithread support. I changed the config in the pharo generator.image to use the cogmt config and was able to build a vm. But this vm crashes on startup. (windows7) Is this the right way and did anyone got this to work (windows or linux)? And can this work to make NB callbacks working for multithreaded libraries. (I made some simple bindings for the gstreamer lib with NB, this works for simple calls (create element/change state). But I guess this won't work for any gstreamer function that requests a callback that may b e called from a different thread) Would this be the right way to do: - build a vm with MT support - guard the NB callback entry/leave code with the ownVM()/disownVM() call. Or is there more to do. Thanks in advance nicolai
Nicolai If I remember igor wanted to manage the threaded code at the level of NB by creating all the machinery there. Now talking with Eliot and clement, they have a design of Threaded FFI that is definitively something that we need people to help on. Clement told me that the design was not complex and inspired from a python one. (but I may be wrong). Clement? Stef
I've tried to build a pharovm with multithread support. I changed the config in the pharo generator.image to use the cogmt config and was able to build a vm. But this vm crashes on startup. (windows7)
Is this the right way and did anyone got this to work (windows or linux)?
And can this work to make NB callbacks working for multithreaded libraries.
(I made some simple bindings for the gstreamer lib with NB, this works for simple calls (create element/change state). But I guess this won't work for any gstreamer function that requests a callback that may b e called from a different thread)
Would this be the right way to do: - build a vm with MT support - guard the NB callback entry/leave code with the ownVM()/disownVM() call.
Or is there more to do.
Thanks in advance
nicolai
Hi, 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 :) Time ago Eliot did a prototype (more than a prototype in fact, but still far from âproduction readyâ) to have Threaded FFI and Iâm quite sure this is the way to go, at least as a 1st milestone. I already have a process building this experimental VM: https://ci.inria.fr/pharo/view/VM/job/CogMTVM/ <https://ci.inria.fr/pharo/view/VM/job/CogMTVM/> (No idea why windows build failed last two times⦠this can be a random fail). I do not remember exactly the changes needed in the image to take advantage of it⦠it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this⦠no idea where it is now (if is already incorporated in latest FFI, which we have). Then, after this⦠I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but Iâm just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better⦠I will let Eliot to explain better). TL;DR: Start for the CogMTVM, is the way to go. cheers, Esteban
On 17 Apr 2015, at 09:06, Nicolai Hess <nicolaihess@web.de> wrote:
Hi,
I've tried to build a pharovm with multithread support. I changed the config in the pharo generator.image to use the cogmt config and was able to build a vm. But this vm crashes on startup. (windows7)
Is this the right way and did anyone got this to work (windows or linux)?
And can this work to make NB callbacks working for multithreaded libraries.
(I made some simple bindings for the gstreamer lib with NB, this works for simple calls (create element/change state). But I guess this won't work for any gstreamer function that requests a callback that may b e called from a different thread)
Would this be the right way to do: - build a vm with MT support - guard the NB callback entry/leave code with the ownVM()/disownVM() call.
Or is there more to do.
Thanks in advance
nicolai
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 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
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
Le 18/04/2015 19:57, Ben Coman a écrit :
On 18/04/2015 3:36 pm, "Esteban Lorenzano" <estebanlm@gmail.com <mailto: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 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?
Reuse the transactional memory stuff for Pharo which already exist? Thierry
Cheers -ben
participants (6)
-
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
Nicolai Hess -
stepharo -
Thierry Goubier