cvs commit: src/sys/i386/include tls.h src/gnu/usr.bin/cc34/cc_prep/config dragonfly-spec.h src/gnu/usr.bin/cc34/cc_prep/config/i386 dragonfly.h src/lib/csu/i386 crt1.c src/lib/libc/gen tls.c src/lib/libc/i386/sys cerror.S src/lib/libc/include libc_private.h ...
davidxu at freebsd.org
Wed May 11 18:54:06 PDT 2005
Matthew Dillon wrote:
Well, I wasn't really planning on putting the user critical
section data in the TCB... but now that you bring it up I
don't see why we couldn't do it.
Basically the way I intend to implement the userland critical
section is by creating two procedures in the syscall layer
to enter and exit the userland critical section. That is, as
far as userland is concerned these would be system calls.
But the actual implementation in the syscall layer would not
have to make an actual system call. I was thinking that it
would 'register' a bit of shared memory (not necessarily
TCB related) that both it and the kernel could mess around
There are other reasons for my wanting to do things this way.
There are a ton of things we can put in such a shared
memory segment. The pid, a copy of the current creds,
the current time of day (tick resolution or seconds resolution
only of course), and so on and so forth. For this sort
of use to be portable the userland program and libraries should
not be allowed to directly access the data but instead would
access it via 'fake' system calls in the syscall layer.
I need fast critical section, otherwise I can just use sigprocmask
everywhere, the critical section has to be per-thread based, a
shared memory page won't work. one thread blocking signal shouldn't
stop other threads to process signal.
<dillon at xxxxxxxxxxxxx>
More information about the Commits