Asynchronous syscalls for massive concurrency

[Peter Schuller]

> KSE's asynchronous system calls could be used to do what you suggest
> however it turns out that if you are going to do this you probably want to 
> do it in a way where the program is aware of what is going on,
> so the ability to make all syscalls "TRANSPARENTLY ASYNCHRONOUS" is
> not really a requirement.

I did not mean to imply it had to be transparent; in fact that was not
my goal. But I see it as a problem that, right now, if a process
wishes to make n concurrent system calls (concurrent in the sense of
the time period between request to response, not actually concurrent
in terms of execution in the kernel or in user space), it *must* have
n threads (or n co-operating processes). In other words, there is an
enforcement that logical concurrency be matched with actual
machine/kernel concurrency.

This makes userland threading non-transparent (from the perspective of
application code written in a language or framework that attempts to
provide light-weight concurrency) because you can suddenly not count
on all operations playing well with it. Basically, disregarding tricks
that do things like offloading certain operations to separate
processes (which still does not remove the n process/n thread
requirement), any light-weight concurrency implementation is not
generally applicable.

That is, you are forced to trade trade light weight against a
restricted feature set.

> The async syscall part of KSE could be kept/reintroduced pretty
> seperatly from the thread support part, but it really requires
> someone to decide how to use it.

The intended use would be to augment exiting code to take advantage of
it. If it caught on among operating systems, it would be a big step
forward in my opinion, from the perspective of application
development. If a single or a few operating systems did it, they would
have an advantage to the extent that someone actually implements the
necessary support in $language_or_framework.

In particular various higher level languages where it would make a
huge difference to be able to support this in the interpreter/vm/core
library. It would remove, or lessen, the need to differentiate between
"not quite threads" and "threads" (witness stackless python tasks or
ruby fibers, vs. the actual native threads in Python and Ruby 1.9;
once again trading light-weight vs. generality).

As far as I can see, it can be applied to the C runtime library as
well, but the advantage would be less since you won't get around the
need to maintain a per-thread native stack.

This latter point is why I am mostly interested in it from the higher
level language perspective, where higher level primitives (e.g.,
continuations, interpreter level stacks on the heap, etc) can be used
for thread context instead of the native stack, thus removing the need
to take an <n> kbyte hit per thread just for the stack alone. It is
not even mutually exclusive to native code compilation.

Oh and btw, regarding my comment on paging: While as far as I can tell
it holds relative to native threading, it is still not worse (better
in fact) than the single-threaded state machine model where a
high-latency paging operation blocks the entire process.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080319/004e6884/attachment.pgp