> > ret = cmpxchg(&last_cycle, last, new); > > if (ret == last) > > return new; /* you win! */ > > else > > return ret; /* you lose. ret is winner's new */ > > Interesting solution. But there may be multiple updates of last happening. > Which of the winners is the real winner?
It might not matter. Let's look at how good a guarantee an application can expect from gettimeofday(). First of all there may be arbitrary delays either before, or after the kernel comes up with the "current" time since the process could be context switched in the glibc prologue or epilogue for the system call. So I think that the best that an application can expect is: Given two calls to gettimeofday A and B, where through some external syncronization it is known that call B is initiated after A has completed, then B shall not return a time value lower than that returned by A. Now if that is the strongest ordering that an application can expect (and I'm not completely convinced that I'm right, other definitions gratefully accepted), then it would appear that is is just over-engineering to worry too much about calls that collide inside the kernel (since these don't satisfy the "B initiated after A completes" clause of my definition). -Tony [For some 50 year old British humour on the subject of time, read: http://www.hexmaster.com/goonscripts/what_time_is_it.html ] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
