Resource Manager Time Stamps

bridged with qdn.public.porting
Post Reply
Bill Caroselli

Resource Manager Time Stamps

Post by Bill Caroselli » Tue Feb 18, 2003 11:26 pm

I'm looking at porting a mountain of code from QNX4 to QNX6. I'm
reading the helpviewer section: QNX Neutrino RTOS 6.2 -> Writing a
Resource Manager -> Data Carrying Structures -> The Attribute Structure.

(A fairly large section of that is copied below for convienence).

It implies that the timestamps are NOT necessarily accurate. I (think
I) understand why and when they *are* updated. My question is this:

If a certain piece of data was modified on one host at a certain time,
and a corrisponding piece of data was modified on a different host at
a different time, and there were no interviening fstat() calls made on
the respective hosts, then there is no way of knowing reliably which
piece of data was updated more recently. Is that correct?

The software I'm porting is mirroring software. It is assumed that
whichever system had it's file updated more recently has the more
reliable version of the data, whatever the data may be. Note that
it's entirely possible that niether files have actually been closed.
I'd still like to know which one was written to more recently.

NOTE: Yes, I do compensate for systems clocks being set differently.

--------------
mtime, atime, and ctime
The three POSIX time members:
o mtime -- modification time (write() updates this).
o atime -- access time (read() updates this).
o ctime -- change of status time (write(), chmod() and chown() update
this).

------------------------------------------------------------------------

One or more of the three time members may be invalidated as a result of
calling an iofunc-layer function. This is to avoid having each and every
I/O message handler go to the kernel and request the current time of
day, just to fill in the attribute structure's time member(s).
------------------------------------------------------------------------

POSIX states that these times must be valid when the fstat() is
performed, but they don't have to reflect the actual time that the
associated change occurred. Also, the times must change between fstat()
invocations if the associated change occurred between fstat()
invocations. If the associated change never occurred between fstat()
invocations, then the time returned should be the same as returned last
time. Furthermore, if the associated change occurred multiple times
between fstat() invocations, then the time need only be different from
the previously returned time.


--
Bill Caroselli -- Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

Bill Caroselli

Re: Resource Manager Time Stamps

Post by Bill Caroselli » Tue Feb 18, 2003 11:38 pm

Bill Caroselli <qtps@earthlink.net> wrote:
If a certain piece of data was modified on one host at a certain time,
and a corrisponding piece of data was modified on a different host at
a different time, and there were no interviening fstat() calls made on
the respective hosts, then there is no way of knowing reliably which
piece of data was updated more recently. Is that correct?
For the record, I'm NOT refering to a resource manager that I am writing.

I'm refering mostly to the QNX filesystem. But also to any filesystem
in general.

Bill Caroselli

Re: Resource Manager Time Stamps

Post by Bill Caroselli » Tue Feb 18, 2003 11:53 pm

The more you think about it, and read different questions in these NGs,
there really should be a /dev/shmem/time that you can mmap() into your
program. The timer interrupt routine can update this structure. That
way you can query it as often as you wnt to almost no overhead.

It would be nice if it used a struct timespec. In order to not have
to use a semiphore in the interrupt handler you could just have a cover
function that read it twice. That way it could catch the very rare
instance of catching it before the tv_sec was updated by the interrupt
handler but after the tv_nsec was updated.

Sean Boudreau

Re: Resource Manager Time Stamps

Post by Sean Boudreau » Wed Feb 19, 2003 1:40 am

struct qtime_entry *qtp = SYSPAGE_ENTRY(qtime);

Bill Caroselli <qtps@earthlink.net> wrote:
The more you think about it, and read different questions in these NGs,
there really should be a /dev/shmem/time that you can mmap() into your
program. The timer interrupt routine can update this structure. That
way you can query it as often as you wnt to almost no overhead.

It would be nice if it used a struct timespec. In order to not have
to use a semiphore in the interrupt handler you could just have a cover
function that read it twice. That way it could catch the very rare
instance of catching it before the tv_sec was updated by the interrupt
handler but after the tv_nsec was updated.

Robert Krten

Re: Resource Manager Time Stamps

Post by Robert Krten » Wed Feb 19, 2003 1:31 pm

Bill Caroselli <qtps@earthlink.net> wrote:
The more you think about it, and read different questions in these NGs,
there really should be a /dev/shmem/time that you can mmap() into your
program. The timer interrupt routine can update this structure. That
way you can query it as often as you wnt to almost no overhead.

It would be nice if it used a struct timespec. In order to not have
to use a semiphore in the interrupt handler you could just have a cover
function that read it twice. That way it could catch the very rare
instance of catching it before the tv_sec was updated by the interrupt
handler but after the tv_nsec was updated.
That would be awful! Wasting a whole 4k page for what, a few bytes?
It would be much better if it was in the syspage :-) :-)

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Robert Krten

Re: Resource Manager Time Stamps

Post by Robert Krten » Wed Feb 19, 2003 1:31 pm

Sean Boudreau <seanb@node25.ott.qnx.com> wrote:
struct qtime_entry *qtp = SYSPAGE_ENTRY(qtime);
D'oh! :-)
Bill Caroselli <qtps@earthlink.net> wrote:
The more you think about it, and read different questions in these NGs,
there really should be a /dev/shmem/time that you can mmap() into your
program. The timer interrupt routine can update this structure. That
way you can query it as often as you wnt to almost no overhead.

It would be nice if it used a struct timespec. In order to not have
to use a semiphore in the interrupt handler you could just have a cover
function that read it twice. That way it could catch the very rare
instance of catching it before the tv_sec was updated by the interrupt
handler but after the tv_nsec was updated.
--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Bill Caroselli

Re: Resource Manager Time Stamps

Post by Bill Caroselli » Wed Feb 19, 2003 6:08 pm

Sean Boudreau <seanb@node25.ott.qnx.com> wrote:
struct qtime_entry *qtp = SYSPAGE_ENTRY(qtime);

Bill Caroselli <qtps@earthlink.net> wrote:
The more you think about it, and read different questions in these NGs,
there really should be a /dev/shmem/time that you can mmap() into your
program. The timer interrupt routine can update this structure. That
way you can query it as often as you wnt to almost no overhead.
Cool. I didn't know this.

So I can assume this is a low overhead call?
(at least lower overhead than calling time(0))

Is there a chance in hadies that a furure OS version might stick the
tv_nsec part after the seconds since boot part?


I *do* see that it is interrupt handler safe. Cooler Still!

Steve, you might want to put a comment on the time() page that if you
need this in an interrupt handler, this is a viable alternative.
Granted, the caller will have to do the math.

David Gibbs

Re: Resource Manager Time Stamps

Post by David Gibbs » Thu Feb 20, 2003 11:47 pm

Bill Caroselli <qtps@earthlink.net> wrote:
It implies that the timestamps are NOT necessarily accurate. I (think
I) understand why and when they *are* updated. My question is this:

If a certain piece of data was modified on one host at a certain time,
and a corrisponding piece of data was modified on a different host at
a different time, and there were no interviening fstat() calls made on
the respective hosts, then there is no way of knowing reliably which
piece of data was updated more recently. Is that correct?
Not quite. If there were no intervening fstat() or close() calls.

That information is required to be updated on close() as well.

(I'm not sure whether it is any close(), or only the final close() of
dup'ed fds.)

-David
--------------
mtime, atime, and ctime
The three POSIX time members:
o mtime -- modification time (write() updates this).
Anything that modifies the contents modifies this -- generally write(),
but for some devctl()s it might be appropriate to modify this, a
ftruncate() might modify this as well.
o atime -- access time (read() updates this).
o ctime -- change of status time (write(), chmod() and chown() update
this).
ftruncate() should.

utime() could modify all of them.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Post Reply

Return to “qdn.public.porting”