[m-dev.] questions about grades

[Paul Bone]

On Wed, Feb 24, 2016 at 01:15:50PM +1100, Zoltan Somogyi wrote:
> 
> 
> 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?

If I understand you: yes.

Because .par means something different on each backend, I find it hard to
distill what .par means for all backends.  The closest sucsinct description
that is truthful is "thread safety and concurrency support".

Yes, Mercury thread A can block Mercury thread B by doing blocking IO in the
low-level C grade.  That's a seperate long-standing problem.  Fixing it
directly would be best: supporting better IO in low level grades and adding
parallel conjunctions to other grades.  Otherwise we can now describe it in
terms of constraints.  This kind of thing was discussed with the original
proposal, linked in with the language features feature.

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

Okay, I'm just checking, I know (or think I knew!) what a grade is before
these changes.  I'm clarifying what it is after the changes.  I don't know
if java and java.par were the same before these changes, I never tested
that.

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

That makes sense to me.  I'd prefer to stick to the simplier looking names.


-- 
Paul Bone