[m-dev.] questions about grades

[Paul Bone]

On Wed, Feb 24, 2016 at 12:32:46PM +1100, Zoltan Somogyi wrote:
> On Wed, 24 Feb 2016 11:37:35 +1100, Peter Wang <novalazy at gmail.com> wrote:
> > > We allow a .par grade component to be added to a grade regardless of
> > > what language we are targeting, but I have used only the LLDS .par grades
> > > For those, the .par grade component means: multiple engines, reserve a register
> > > for thread local data, and support for executing code in parallel, both
> > > code that explicitly spawns off processes with thread.spawn, and code that
> > > just uses parallel conjunctions. However, I vaguely remember that the .par
> > > grade component means something different for the other targets: high level C,
> > > Java, C# and Erlang, and not just in that they don't have a register to
> > > reserve. Can the people who have implemented and/or used .par for these
> > > targets tell me what the differences are, if there are any?
> > 
> > It means the user can create Mercury threads with the thread module.
> 
> But it does not imply the availability of parallel conjunctions? Then,
> what does? Paul?

Parallel conjunctions are supported for low level C backends with the .par
grade component.  For a long time we have talked about adding this to the
hlc backend but haven't yet done it.

This is a very tricky part of the configuration process for users to
navigate.  Parallel conjunctions require low level C, but if you do IO and
multithreading then the low-level backends don't currently work very well,
you either have to use spawn_native or use high level C, but the you loose
parallel conjunctions.  There isn't a good option if you want: parallel
conjunctions, IO and lightweight threads.


> > For high level C, that requires thread-aware Boehm GC, C library,
> > compiling with _REENTRANT, etc.
> 
> So how do we now handle platforms on which either Boehm or glibc
> is not thread-aware? When do you get an error message? Do we need
> a solver var, set from autoconfiguration results the same way as
> gcc_regs_avail, to say whether .par is available for C?
> 
> > For Java and C#, the runtimes are always thread-aware so
> > .par means nothing more than the base grade.
> 
> So, basically targeting Java and C# would imply .par? With the constraint
> based solver, it would be trivial to implement the implication, so that e.g.
> java and java.par would be the same grade.

Does that mean installing the grade twice?  Can I link a java.par
application with a java library (no .par)?


-- 
Paul Bone