Fast gettimeofday(2) and clock_gettime(2)

[Bruce Evans]

On Thu, 7 Jun 2012, John Baldwin wrote:

> On Wednesday, June 06, 2012 9:35:49 pm Bruce Evans wrote:
>> On Wed, 6 Jun 2012, John Baldwin wrote:

>>> 1) You don't follow the model of clearing tk_current to 0 while you
>>>   are updating the structure that the in-kernel timecounter code
>>>   uses.  This also means you have to avoid using a tk_current of 0
>>>   and that userland has to keep spinning as long as tk_current is 0.
>>>   Without this I believe userland can read a partially updated
>>>   structure.
>>
>> I thought that too at first, but after looking at the patch decided
>> that it may be correct, but is too hard for me to understand.
>> Urk, we both missed that tk_current is an index into the timehands
>> array, so it cannot act as a generation count and it seems to be harder
>> to lock.
>
> Ugh, so it goes a long way to emulate the timehands array in userland.  As I
> mentioned previously, I consider the timehands array to be a bug.  However, I
> do think the generation count in the in-kernel timehands structure is useful
> and should be kept (and follow the same model of setting it to 0 before doing
> updates, then updating the structure, then setting the new generation).

Without the timehands array you will need slow atomic ops or maybe MD magic
to make them unnecessary.

I think 3 generations are necessary and sufficient: one pointed to by
timehands for normal use; another that used to be pointed to be
timehands and that remains valid for 1 more generation time after
timehands was switched away from it, and one
invalid/unready/being_updated one that will become the one pointed to
by timehands 1 generation after it was updated.  2 generations are
needed instead of 1 to allow updating one while the other remains
usable, and 3 generations are needed instead of 1 to ensure that the
one pointed to by timehands remains valid for a full generation time
(average 1.5 generation times) after any read of timehands.

Bruce