Threads

[Emmanuel Blot]

Hi,

I'm looking for a way to support threads in a Minix 3.3 application.

AFAIU, Minix does not support kernel threads in applications.

It seems that the VFS supports some kind of user threads, with the
help of the libmthread library. It seems to support cooperative
multitasking, but I did not find any support for pre-emptive
multitasking.

I also find some projects such as utrix, which has not been active for
over 5 years and targets a previous release of Minix (3.1)

Is there any way to achieve pre-emptive multitasking in a single
process on Minix?

Thanks,
Manu

[David van Moolenbroek]

Hey Manu,

On Thursday, April 9, 2015 at 3:33:49 PM UTC+2, Emmanuel Blot wrote:

AFAIU, Minix does not support kernel threads in applications.

Indeed; in fact, it does not have support for kernel threads at all.
 

Is there any way to achieve pre-emptive multitasking in a single
process on Minix?

For application processes, this would involve setting a timer (setitimer(2) or alarm(3) etc), and performing a process-local thread context switch upon getting the corresponding signal (SIGALRM or SIGVTALRM etc). There are some threading libraries that can do this, IIRC including FSU Pthreads [1]. Unrelated to the dead minix links on that page, I ported that library to minix once [2], but that's now 8.5 year ago (..oh my), and a new port might be easier to do. There are probably other threading libraries, possibly somewhat less ancient, that can do the same.

Regards,
David

[1] http://moss.csc.ncsu.edu/~mueller/pthreads/
[2] http://www.cs.vu.nl/~dcvmoole/minix/software/fsu-pthreads-3.14.tar.bz2

[Emmanuel Blot]

Hi David,

Thanks again for the details and references, I'll have a look at all these.

Is kernel threads something envisionned for the "near" future of Minix?

There are two features that - I think - would be really nice for Minix
- if one of the targets is the embedded world:
* pthreads support
* lightweight libC library - Musl could be a nice candidate for example

Both are likely to be heavyweight in term of work effort I guess :-)

Thanks,
Manu

> --
> You received this message because you are subscribed to the Google Groups
> "minix-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to minix-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David van Moolenbroek]

Hey,

On Wednesday, April 22, 2015 at 9:42:53 AM UTC+2, Emmanuel Blot wrote:

Is kernel threads something envisionned for the "near" future of Minix?

I'm afraid not. It would be a massive undertaking, mainly because all the core system servers would have to be rewritten to differentiate between process-local and thread-local state, and to take into account the possibility that part of the process is running while a system call is being made (by another thread). The benefits are not so clear.
 

There are two features that - I think - would be really nice for Minix
- if one of the targets is the embedded world:
  * pthreads support

This can mean various things. For example, libmthread already implements a large subset of the pthreads API/standard, and the GNU Pth package has a fullblown implementation AFAIK. Preemption and/or kernel support are not a requirement for pthreads, even though of course either may be needed for some applications.

  * lightweight libC library - Musl could be a nice candidate for example

Hmm, I thought the netbsd libc wasn't very heavyweight to begin with?

Regards,
David

[Emmanuel Blot]

>> Is kernel threads something envisionned for the "near" future of Minix?

> I'm afraid not. ../.. The benefits are not so clear.

True. Just curious.

> This can mean various things.

Yes, it does not require kernel threading support.

> For example, libmthread already implements a
> large subset of the pthreads API/standard,

I might be wrong, but I understood it did not support pre-emption,
only cooperative multithreading.
Does libmthread support pre-emption ?

>> * lightweight libC library - Musl could be a nice candidate for example
> Hmm, I thought the netbsd libc wasn't very heavyweight to begin with?

Well, on ARM a stripped, statically linked version, of

#include <stdio.h>
int main()
{
printf("Hello, World\n");
return 0;
}

weights 315 KiB ...
It is definitely not GNU libc, but still heavy.

musl is supposed to be much lighter (I have not tested it on Minix :-)):
http://www.etalabs.net/compare_libcs.html

A non-trivial embedded system is likely to require "some" storage
space, especially if you need to have multiple concurrent processes
(vs. threads) and without dynamic lib support...

This is probably not a big issue with BeagleBoards, new RPis, etc. but
on devices that embed RAM & Flash in the 10's MiB range, this could be
a show stopper.

A full Minix system is more in the 100's MiB range, but the Minix
"core" (kernel, system servers/fs, ...) could be used on smaller
devices.

Cheers,
Manu

[David van Moolenbroek]

On Wednesday, April 22, 2015 at 5:17:53 PM UTC+2, Emmanuel Blot wrote:

I might be wrong, but I understood it did not support pre-emption,
only cooperative multithreading.
Does libmthread support pre-emption ?

Neither of them do, but then the pthreads standard does not require preemption either. My (not-so-important) point was that depending on how you look at it, we already have pthreads support. A preemptive implementation would be nice of course, especially one that properly wraps all interruptible system calls to support the preemption the best I can. For example, I believe that FSU Pthreads (or was it the other one I ported, of which I can't remember the name?) only wraps the BSD socket API that way.

It is definitely not GNU libc, but still heavy.

Fair enough. I think that if the minix/system-call specific part could be shared between the regular libc and the lightweight one, we'd be happy to merge such a lightweight library, license permitting of course.

Regards,
David