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 ...

David Xu 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
    with.

    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.
					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>
David Xu





More information about the Commits mailing list