[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.

Paul Bone paul at bone.id.au
Fri Jun 27 16:12:58 AEST 2014


On Fri, Jun 27, 2014 at 03:56:23PM +1000, Peter Wang wrote:
> On Fri, 27 Jun 2014 14:58:21 +1000, Paul Bone <paul at bone.id.au> wrote:
> > 
> > Hi, we're working on the same code so I thought I'd let you know what my
> > intentions are here WRT threading on Java.
> > 
> > I'm writing some thread pool code for Java that will make tasks (created by
> > spawn, and in the longer term parallel conjunctions) cheaper.  That is they
> > will be closures until they begin execution (like sparks).  I have no
> > problem with implementing spawn_native as a full Java thread and intend to
> > do this.
> 
> Is there any reason to do so in the standard library?  You can create a
> thread pool in the user program and feed them closures via a channel.

I've been adding it in java/runtime/  but it affects the library.

The problem with having multiple pools (what will happen if every (part of)
an application and it's libraries implement their own pools) is that nested
parallelism will create inefficiencies.  Setup and tear-down of each thread
pool plus each thread pool creating P workers that have to context-switch
with each other.  These effects get much worse if the multithreading code is
recursive.

My intention is to have one of these to manage the concurrency and
parallelism for a whole Mercury program in order to avoid the above
problems and to make parallel conjunctions feasible.

> For parallel conjunction, I've seen that Java has some builtin classes
> that could help, like ForkJoinPool?  I haven't really looked into it.

I've had a look at some of these, I didn't find one what met my
requirements.  At the time I wanted to handle stream parallelism in Java
code.

I'd like to have a Mercury program that uses parallelism and it's own thread
pool, and also use stream parallelism in Java code which is also part of the
application.  In this scenario I'd like to be able to have one thread pool
manage both sources of parallelism.  But I haven't thought that idea through
completely yet. 


-- 
Paul Bone



More information about the reviews mailing list