On Fri, Mar 31, 2000 at 12:50:51AM +1000, Alfred Perlstein wrote:
>What I'm calling for is a vote if we'll rely on this type of behavior
>(32 bit stores being atomic with respect to readers) or not, or
>perhaps to rely on it but mark it somehow so people can "fix it"
>if the need arises later by u
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> I'm aware of this, the problem is that tz may move in either
> direction.
Why not just ignore the timezone argument? That hasn't been relevant
for a long time. The timezone information is kept in user-space.
>From gettimeofday(2):
Note: time
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> 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 cal
> 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
* Jonathan Lemon <[EMAIL PROTECTED]> [000329 21:52] wrote:
> In article [EMAIL PROTECTED]> you
>write:
> >
> >I'm aware of this, the problem is that tz may move in either
> >direction. Hence my question about using sizes that are machine
> >atomic for read/write. :)
> >
> >I've got several book
In article [EMAIL PROTECTED]> you
write:
>* Allen Pulsifer <[EMAIL PROTECTED]> [000329 21:05] wrote:
>> 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 noth
* Allen Pulsifer <[EMAIL PROTECTED]> [000329 21:05] wrote:
> 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
> stru
, March 29, 2000 11:36 PM
> To: Alfred Perlstein; Mike Smith
> Cc: Matthew Dillon; [EMAIL PROTECTED]
> Subject: RE: Using packed structs to gain cheap SMP primatives
>
>
> Here's another alternative for reading structures like time
> that always change monotonically: re
ilto:[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] wro
< said:
> 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)
Generally, it's better to design an optimistic or non-blocking
algorithm rather than twisting data structures to fit some
pre-conceived machine model j
* 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
> > >
11 matches
Mail list logo
