[m-dev.] questions about grades

[Zoltan Somogyi]

On Wed, 24 Feb 2016 12:49:47 +1100, Paul Bone <paul at bone.id.au> wrote:
> 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.

Ok. It sounds like this is something that will only be fixed *after* we switch
to constraint based grade specification, so the solver will implement the
current scheme. In this, if I understand you correctly, the .par grade component
DOES mean the same intention on all the targets that support it (LLDS C, MLDS C,
Java, C#), they just have different limitations wrt how closely the implementation
approaches the intention, in terms of things such as Mercury thread A being
unnecessary blocked by Mercury thread B tying up a pthread. Is this correct?

> > > 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? 

No.

> Can I link a java.par
> application with a java library (no .par)?

Yes. In both cases, the key is that the name of the directory
containing the installed grade, and the grade variable that does
the link-time consistency check, would both use the canonical
version of the grade. Both java and java.par would map
to the same canonical grade, because the solver would map
them both to the same set of solver var value assignments
in the solved form of the constraint system. THAT is what
a grade is; a grade name such as hlc.gc is just a shorthand for
referring to such a set of assignments.

The name of that canonical grade could be either java or java.par,
with the inherent thread safety of the java target being implicit
in the former and explicit in the latter. The former is shorter,
the latter is more meaningful. The principle we implicitly use in the
current set of grade names is that implied components are not explicitly
written in user-visible grades, which would imply choosing "java"
as the name of the canonical grade.

Zoltan.