Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)

Peter Jeremy wrote:
> SunOS 4 (not sure about SunOS 5) exports a per-CPU page that
> includes a high-resolution timer amongst other things.
> 
> On Wed, 10 May 2006, David Xu wrote:
>> One of the problems to implement it is that atomic operations,
>> if there are multiple integer needs to be updated by kernel,
>> userland maybe gets an inconsistent result, the way to avoid the
>> problem is using two generation numbers.
> 
> A lot of the need for atomic operations goes away if the page (or
> whatever) refers to the current CPU - the page is either being updated
> by the current CPU in kernel mode or read by the current CPU in
> userland.  The page won't be updated/accessed by other CPUs.  You
> still need to update the base time and TSC (or whatever) count in a
> way that looks atomic to userland but I suspect the kernel could
> achieve this by twiddling the code transparently to userland (eg there
> are two copies of the base/count and the kernel flips a pointer
> between then).
> 
> On Wed, 2006-May-10 12:01:57 +0800, David Xu wrote:
>> Daniel Eischen wrote:
>>> Can you not make a simple pseudo device driver and mmap the page?
>>>
>> mmap is fine if you don't care binary compatible, exporting a kernel
>> page which can be executed by userland is more flexible, kernel can
>> change it freely without having to change libc.
> 
> These aren't mutually exclusive - .so's are mmap'd.  All libc needs
> to do is mmap a page from a pseudo device and execute a function in
> it.  Either the function could be at a magic address or the pseudo
> device could simulate a shared object so you just dlopen() the device.
> 

How about making the scheduler insert the current time into something
resembling in functionality of a cpu local variable (register? cache
area?) whenever there is a context switch by the scheduler. Then
whenever you need the current time the userland application would read
it off this cpu local variable/holy area requiring no additional context
switch.

Or do the currently running (on that cpu) userland application require
the ability to read the current time more often than once per "time
slot"? Do i make sense?

*ducks for cover*

-- 
Sten Daniel Sørsdal