|Anonymous | Login | Signup for a new account||2013-05-20 09:44 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005457||OCaml||OCaml general||public||2011-12-30 16:09||2012-01-17 21:28|
|Target Version||Fixed in Version|
|Summary||0005457: Wish: Sys.critical|
|Description||"Sys.critical : unit -> unit" would run a function with the additional guarantee of the runtime that no asynchronous actions occur that lead to the execution of other Ocaml code.|
Asynchronous actions would be: Thread switches, Signals, GC finalisers, GC hooks. Events that would lead to the execution of such actions are delayed until the critical section ends. Sections can be nested.
Asynchronous events are characterized by the fact that they cannot be controlled by the programmer in any way. The plan is to add a basic way of control.
|Additional Information||What I have in mind is a counter that is increased at the beginning of the section, and is decreased at its end (regular or via exception). Delaying thread switches and signals is probably trivial (just don't do when the counter is > 0, and check again when the counter is decreased). The GC callbacks need probably a bit of work as the actions need to be saved, so they can be run when the counter is zero again.|
There are two motivations: (1) It would give the programmers a very light-weight way of protecting shared resources. (2) It solves problems of the interaction between GC hooks and other asynchronous events. For example, in a multi-threaded program it is currently almost impossible to mutate a global variable from a GC hook in a safe way (other than trivial cases), because you cannot protect the variable with a mutex. If the GC hook wants to get the mutex, it might already been locked (leading to deadlock).
This might also serve as clean solution for 0005436
|Tags||No tags attached.|
Another use cases: The Random module could become thread-safe
There are also (rare) occasions where you are changing the global properties of a process temporarily, and you don't want that other threads see this (e.g. chdir, umask)
Preventing preemption between threads is easy -- the bytecode threads implementation (otherlibs/threads) does it to implement mutex. Preventing other forms of context switches between threads (e.g. a thread blocks on a Unix.read) feels weird to me. I'm a bit unsure about signals, and very unsure about GC-related actions. Queuing finalizers to be run later sounds painful to implement.
Interesting reaction. I was prepared to hear more fundamental objections, e.g. that this change makes all other approaches to integrating multi-threading more difficult or impossible (especially those targeting multicore). Or that programmers could use the feature in the wrong way, and especially keep the lock for too long.
My intention is that it becomes easier to program signal handlers and GC hooks in Ocaml. I've more than once moved such code, especially finalizers to the C level, because I get there implicitly the described effect. If you stick to Ocaml, you often cannot do more than setting some flag, and do the real finalization later. As an example look at the memory pool implementation in Ocamlnet: https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netsys/netsys_mem.ml [^] (at the end of the file, look for type memory_pool). A memory pool is a manager for page-aligned bigarrays of char. The finalizer cannot here do much, because in a multi-thread program it is impossible to lock the data structure from the finalizer (deadlock danger). In this case, it was possible to just delay finalization, but I can imagine other cases where one does not want this, because the resources to free are more valuable than just memory.
If Sys.critical would only prevent preemption and maybe signal handlers, it would already make a lot of such things easier (especially in a finalizer, because the execution of finalizers is serialized anyway). The idea to also include GC hooks in general is just for completeness of the concept.
|Your assumption was correct, we discussed the issue, and "fundamental objections" were raised, by those ones who would like to have a multicore runtime soon...|
|2011-12-30 16:09||gerd||New Issue|
|2011-12-31 13:53||gerd||Note Added: 0006576|
|2012-01-14 20:15||xleroy||Note Added: 0006683|
|2012-01-14 20:15||xleroy||Status||new => feedback|
|2012-01-17 15:18||gerd||Note Added: 0006695|
|2012-01-17 15:18||gerd||Status||feedback => new|
|2012-01-17 21:28||lefessan||Note Added: 0006703|
|2012-01-17 21:28||lefessan||Status||new => resolved|
|2012-01-17 21:28||lefessan||Resolution||open => won't fix|
|2012-01-17 21:28||lefessan||Assigned To||=> lefessan|
|Copyright © 2000 - 2011 MantisBT Group|