David Muir wrote in a message to Peter Fitzsimmons:

 DM>     The "general idea" goes something like this. I want to
 DM> "do something" for  60 seconds. While i'm doing that I want
 DM> to count backwards on screen for each  new second.

I'm not sure I see the point of this.  If the machine is so busy that it is
not able to reliably wake up your display seconds thread, then I think it
might be better to miss displaying on that particular iteration.

 DM>     The "original" method was to use the gettime and compare
 DM> the seconds count  (accurate but inefficient). I was hoping
 DM> to replace this thread with an  equally accurate thread that
 DM> was blocked by a semaphore (rather than  dossleep). as more
 DM> and more threads and functions are used, the probability of 
 DM> failing to return from a dossleep in time to catch the
 DM> change increases, thus  leaving me with an unstable timer,
 DM> or one which doesn't display "every" second  (depending on
 DM> how it's implemented). By using a semaphore blocked thread
 DM> this  thread will be awaked "as needed" and will increase
 DM> the odds of accurate  results (although not guarantee them
 DM> if I understand the CPU usage correctly),  so basically
 DM> right now I'm doing this...

This is not going to work.  All these mechanisms do is control when a
blocked thread is flagged as ready to run and placed back into the
scheduler rotation. The differences in these techniques concern how the
thread is blocked, not how it is unblocked.

Because of this, the only way to have any expectation that you will display
every second is to set the thread to run at high priority.  If you do this,
then it will be scheduled quickly after it is flagged ready.  Whether it is
flagged ready because a sleep has expired or because an event semaphore has
been posted that it was waiting for, the sequence of events is largely the
same.  Obviously, a high priority thread should spend most of its time
blocked, or bad things will happen to the rest of the system.

 DM>     What I "want" to do is the same basic concept without
 DM> needing to dossleep  (using semaphores).

I think you should use semaphores to start the timing sequence, rather than
loop on a check to see if a variable is zero or not.  This is not really
your question, however.

 DM> Does any of this make any sense? (can a thread be blocked by
 DM> a semaphore?). 

Of course a thread can be blocked by a semaphore.  However, the exact way
in which semaphores are handled has changed from the 16-bit API to the
32-bit API, and I have no idea how to advise you if you are programming in
Pascal.
 
-- Mike


---