Concurrent Truffle languages and creating threads

[Christian Humer]

> Yes, it is quite integral to SOMns.

That's unfortunate. I expected fork join pools to be composable with other
frameworks.

> Is there going to be an API for efficient thread-local data, too?

Yes context-local and thread-local. This means thread-local data.
Thread-local code has less use-cases, but we might need to support that as
well.

> And if so, what’s the design going to be, roughly?

Something similar to ThreadLocal. Implementation wise we can do fast slots
in the context object that get initialized when the language context or the
local is initialized. So the access should compile to just a read relative
to the current thread pointer and an array read.





On Fri, Sep 29, 2017 at 2:35 PM Stefan Marr <java at stefan-marr.de> wrote:

> Hi Christian:
>
> > On 29 Sep 2017, at 13:29, Christian Humer <christian.humer at gmail.com>
> wrote:
> >
> > I did not think about this. Do you actually use it?
>
> Yes, it is quite integral to SOMns.
> Everything executes on one of 4 fork/join pools (depending on the
> concurrency model).
>
> All threads in my system are consequently subclasses of
> ForkJoinWorkerThread:
> https://github.com/smarr/SOMns/blob/master/src/tools/concurrency/TracingActivityThread.java#L16
>
> > For every thread except integrator threads. We want to allow fast thread
> and context local data for all languages independent of the language that
> created it. That API did not land yet.
>
> Is there going to be an API for efficient thread-local data, too?
> And if so, what’s the design going to be, roughly?
>
> Thanks
> Stefan
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
>
>
>