Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
order that nothing has changed. For example, to read a
structure containing hours, minutes, seconds:
for (;;)
{ h = timep->hour;
m = timep->minute;
s = timep->second;
if (m != timep->minute) continue;
if (h != timep->hour) continue;
break;
}
The assumption is that from the instant you first read
timep->hour until the instant you double check its value,
it could not have wrapped all the way back around to its
previous value. Or to put it another way, if it has
succeeding in wrapping all the way around, having a
correct snapshot of the structure is the least of your
problems and the value you use is arbitary.
This same method can be used to read the MSW and LSW of
any counter-like structure that is updated by an interrupt.
Note this method will not work for a structure that can
both increment and decrement--it has to be only one or
the other.
Allen
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Alfred Perlstein
> Sent: Wednesday, March 29, 2000 10:25 PM
> To: Mike Smith
> Cc: Matthew Dillon; [EMAIL PROTECTED]
> Subject: Using packed structs to gain cheap SMP primatives
>
>
> * Mike Smith <[EMAIL PROTECTED]> [000329 17:03] wrote:
> > > > For the single-process (1-fork) case, syscall overhead improved
> > > > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
> > > > improvement in the competing-cpu's case is due to the movement of the
> > > > MP lock inward somewhat (even for syscalls that aren't MP safe),
> > > > the removal of a considerable number of unnecessary 'lock'ed instructions,
> > > > and the removal of the cpl lock (which benefits spl*() code as well as
> > > > syscall/interrupt code).
> > > >
> > > > I got similar results for calling sigprocmask():
> > >
> > > You should be able to remove the splhigh() from sigprocmask and run it
> > > MPSAFE. At least, I can't find a reason not to (and it works here, yes).
> >
> > Just following on from this, one thing that I can see immediately being
> > very important to me at least is a spinlock in the timecounter structure.
> > Calcru and various other things call microtime(), and we're going to want
> > to lock out updates and parallel accesses to the timecounter. What
> > should we be using for an interrupt-disabling spinlock?
>
> One thing everyone should be aware of is that most archs will support
> atomic read/write of a data value that's under a certail width (and
> aligned properly)
>
> Yesterday I was looking at how Linux handles the gettimeofday stuff
> without locking thier sys_tz variable, well it seems they don't care
> or I'm missing something important.
>
> They just don't lock it, not that settimeofday will be called all that
> often but it leaves me wondering what we can do about this, effectively
> we can pack our tz (sys_tz in Linux) into a 32bit value which should
> afford us read/write atomicity on every platform I'm aware of.
>
> In fact this can be quite effective for certain types of data structures,
> even though our 'struct timezone' is two ints we can pack it into two
> uint16 and pack a private structure, then copy it to a stack and expand
> it into the user's address space.
>
> What do you guys think about that? Am I totally missing something
> that makes the Linux way right/ok? (no locking on a 64bit struct)
>
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
