I don't have any idea to address the original question, but here's another datapoint.

Gauche also supports per-thread parameter table. It is just a flat vector, and a parameter object holds an index to it (the index itself is global; if one thread creates a new parameter object, the slot is reserved in every thread). parameterize saves the old values in lexical environment, and uses after/before handlers to swap values. Call/cc captures the chain of those dynamic handlers.

So, invoking a continuation created by another thread rewinds the parameterize effect in the current thread, then replays the parameterize effect in another thread.

Persistent hashmap is ok for R7RS parameters, but I think it gets tricky to support srfi-39 mutable parameters, doesn't it?

On Thu, Sep 28, 2017 at 10:36 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Note that the dynamic extent is more than just the binding of parameter objects. The pre- and post-thunks of dynamic-wind contribute to the dynamic extent as well.

How do you handle them in multi-threaded code (say in Kawa)? For example, if one thread creates a continuation using call/cc and passes it to another thread, what happens if the continuation is invoked in that other thread?

If parameters are implemented as a per-thread hash map, the system will have to copy that map as well when continuations are invoked, doesn't it? Also in this case, using persistent hash maps as suggested by Arthur seems to make a lot of sense.

Marc

Per Bothner <xxxxxx@bothner.com> schrieb am Do., 28. Sep. 2017 um 16:01 Uhr:
How would one efficiently implement first-class dynamic extends in the presence of threads?

An efficient way to implement parameters is to use a per-thread hash map
from parameter objects to bindings. This has the advantage that accessing or
updating a parameter can be done without locking. It means that the map has to
copied when a new thread is created, but that can be done without locking, and
creating a thread is expected to be a moderately heavy-weight.

Such as strategy makes current-dynamic-extent and with-dynamic-extent somewhat expensive,
since you have to copy the hash-map. Which means creating a srfi-155 promises would be
fairly expensive. Any clever ideas for ameliorating that?

A future is basically a promise using a separate thread, in which case the
copying happens anyway.

(In Kawa, parameters are implemented using ThreadLocal objects - specifically
InheritableThreadLocal objects, which are standard classes in the Java "platform".
A ThreadLocal is implemented using a per-thread map from ThreadLocal objects to values.
A InheritableThreadLocal initializes a new thread's bindings with the binding
from the parent thread.)

--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/
To unsubscribe from this list please go to http://archives.simplelists.com
To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=qt00MfHjvS5CqsEyiYqWul46P18WOKVQ