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 <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.
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.
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.
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.
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.
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.
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.