[m-rev.] for post-commit review: document .par grades

[Peter Wang]

On Sat, 16 Aug 2025 17:07:30 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Sun, 17 Aug 2025 00:41:47 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> 
> > On Sat, 16 Aug 2025 at 23:54, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> > >
> > > On Sat, 16 Aug 2025 23:29:47 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > > Yet you say later that concurrency (using multiple threads, even if on one CPU,
> > > will be supported in "Non .par LLDS grades". What is the reason for this support
> > > being a separate grade modifier for high level C, but a builtin-in capability
> > > in low level C?
> > 
> > In order to support concurrency, something has to have the capability to execute
> > Mercury threads.  In LLDS grades, that something is an engine.  Regardless of
> > whether we are in an LLDS .par grade or not, there will be at least one engine
> > present, so concurrency is always possible (albeit not in parallel in
> > the single engine case).
> > In non .par hlc grades there is nothing to execute the threads, since
> > C does not provide
> > that capability as part of the language. The pthreads library provides
> > the capability and
> > pthreads is only included in the .par grades.
> 
> Ok, that works for me.
> 
> > > > Under this scheme, concurrency will be supported in
> > > >
> > > > 1. The Java and C# grades.
> > > > 2. The hlc.mt grades.
> > > > 3. Non .par LLDS grades (not in parallel)
> > > > 4. .par LLDS grades (in parallel)
> > >
> > > Agreed about 1, 2 and 4. About 3, we should await the results of your test,
> > > and even then, I would need to see something equivalent to a design
> > > document that says how it is supposed to work, because without that,
> > > it cannot be maintained long term.
> > 
> > I tried (3) with asm_fast.gc on some of the concurrency examples earlier this
> > evening.  They seem to work.  That said, so far as I can recall, every
> > discussion
> > I've ever had about this capability is that it doesn't work well.  I would happy
> > to drop it and just not allow concurrency in non .par LLDS grades.
> 
> I would not be affected by a decision either way, so I have no objection.
> Does anyone else on this list have an objection? Peter?

As a recap: the idea is that multiple Mercury threads could be executed
by a number of Mercury engines, which themselves are scheduled by the OS
onto multiple cores/hardware threads. (Note: there is some disabled code
to pin Mercury engines to specific cpus/cores, but I think that is not a
good idea to do in general.)

Under this scheme, you can have concurrent Mercury threads in a non-.par
grades. As Julien found, it works for programs that just test the
concurrency primitives. In practice, the Mercury standard library is
implemented using the usual C/Unix/POSIX synchronous APIs. If a Mercury
thread performs any kind of blocking action, such as reading or writing
a file using the io module, the Mercury engine that it's running on will
be blocked and cannot switch to executing another thread.

It would be a lot of work to make the standard library use asynchronous
APIs (which are all quite disparate across platforms AFAIK), and it
still wouldn't help for operations outside the standard library.
The foreign proc interface would probably need to be redesigned to
accomodate asynchronous APIs. I have no idea how it would look.

The benefit compared to using native threads is unclear. I think in the
mid 90s to early 2000s, threads were somewhat exotic and implementations
were immature, so there was more of a desire to avoid them. I'm not sure
why anyone would make that effort now.

So disabling the capability for concurrency in non-.par grades is
probably okay. I don't know about ripping it out completely, but in
light of the above, it's unlikely it would be revived.

I'm not sure about having separate .par and .mt grade components. Is it
more confusing that you need to use "hlc.mt.gc" but "asm_fast.par.gc" to
get access to multi-threading, which is a practical way to exploit
parallelism? On the other hand, parallel conjunction is just an
experiment feature; there are probably no real programs using it.

Peter