One idea is to have another thread running that keeps time for you. You
just call sleep(x), where x is the level of granularity you want your
timer to have in your thread, and then add 1 to your time variable each
time the thread wakes up. You can have another function that polls the
value of your time variable. The getting and setting functions for the
time variable can have a mutex lock.
-----Original Message-----
From: Cole Tuininga [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 30, 2001 7:19 PM
To: Benjamin Scott
Cc: GNHLUG
Subject: Re: C Question
On Mon, Jul 30, 2001 at 02:50:48PM -0400, Benjamin Scott wrote:
> On Mon, 30 Jul 2001, Cole Tuininga wrote:
> > I'm working on a generic network based lock server.
>
> Back up a step. What are you trying to accomplish? Chances are,
someone
> else has already encountered the problem, and either (a) solved it for
you
> or (b) written the definitive work on why the problem is not easily
solved.
The lockserver project actually started because at the time I wrote it,
mysql did not have row level locking. It's since become used for much
more.
There's some basic client code that one of the guys I work with wrote
to access it. Basically, it accepts a key/index pair and lets you
know if you are in possession of the lock. If not, it lets you know
where in the queue you are.
One of the features that I put into it is the concept of timeouts.
When you make a lock request, you tell the lock server how long you're
willing to wait for it. Additionally, you tell it how long you might
be idle before you either release or renew your lock.
This timing is what I'm trying to accomplish.
If I get a lock at 0:00:00 for instance, and tell it that I have a TTL
of 30 seconds, then if the lockserver hasn't heard back from me by
0:00:30, it should ditch the lock and let whoever is next in line (if
anybody) have it.
The way it is implemented at this point it that when the lock is created
I store the time of creation ( via the time(2) call ). When my cleanup
routine runs, it checks the last "access" time of the lock against the
current time(2) minus the TTL. If appropriate, it releases the lock.
The problem is that the time(2) command gives you system time in
accordance to what time of day the system thinks it is. This is fine
if we were in a perfect world. However, clock skew can occassionally
affect this timing mechanism. If the clock gets off from atomic time
( which seems to happen a lot more often than I would have expected )
and then resynced, the lock timing goes screwy.
What I'm looking for is some sort of method to be able to do timing
within my (soon to be multithreaded) program without relying on
time of day...
Does this explain it well enough?
--
Failure is NOT an option!
It comes bundled with Windows(TM).
Cole Tuininga
Network Admin
Code Energy, Inc
[EMAIL PROTECTED]
(603) 766-2208
PGP Key ID: 0x43E5755D
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
