Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on March 23, 2021 7:16 am wrote:
> Heikki Kultala (heikk.i.kultal.a.delete@this.gmail.com) on March 23, 2021 6:46 am wrote:
> > Veedrac (ignore.delete@this.this.com) on March 23, 2021 3:49 am wrote:
> > > Heikki Kultala (heikki.kultal.a.delete@this.gmail.com) on March 22, 2021 6:52 pm wrote:
> > > >
> > > > The implementation is always free to execute the microthreads sequentially (common case if all our
> > > > hardware microthreads are already in use, for example started by outer level function); programmer
> > > > can write his code/compiler can compile the code like he/it has infinite amount of microthreads
> > > > available. As the bundles execute atomically, different microthreads can still do things like incrementing
> > > > the same counter in memory, but as they are allowed to execute sequentially, they are not allowed
> > > > to wait data from one another microthread because that might cause a deadlock.
> > >
> > > Personally I expect this to be very limiting because it means you must spawn microthreads at the
> > > top level in an order that completely the respects dependencies of all the sub-threads.
> >
> > These are not meant to be spawned at the top level at all. At top level,
> > you spawn normal threads and execute those on totally different cores.
> >
> > These are meant for a limited thing. They are only meant to be a slight bonus
> > on top of a core that has excellent per-thread-performance by other means.
> >
> > These microthreads are for only fully parallel very small
> > things, meant to be used in very small granularity.
> > These are not meant to be replacing normal threads on existing code but to be used for things where threads
> > currently cannot be used because of the overheads. And typically inserted automatically by the compiler.
> > ...
>
> As discussed on previous realworldtech threads about microthreads, you need to
> differentiate a "main thread" which is able to request Operating System services
> (open a file, change processor ring, change TLB for kernel view, ...).
> You cannot have both microthreads request different system services at the same time,
> both handling different interrupt requests, ... you need hyperthreading for that.
> It may even be very difficult to have one microthread requiring system services while the other one continue
> as normal, maybe the secondary microthread can pause while the main microthread requests the OS service.

No need to differentiate, only need to prevent the microthreads from being in different protection modes.

So, when one micro-thread calls any operating system service or gets an exception, all the other microthreads are be halted(and maybe their state flushed to the stack memory), so that they only resume execution until this one has returned from the OS.

This way any micro-thread can call those services, and virtual memory also works, but the microthreads that are active still always are in the same mode.

And the OS routine can actually start it's own microthreads perform it's task faster, when it just joins them before returning.