Conference clt::cma

No signals are involved in pthread_cond_timedwait. When the timer expires,
the waiting thread is removed from the condition variable wait queue and
readied by the DECthreads "manager thread".

Now... what exactly do you mean by "in general I don't prefer using this
kind" ["user mode" timer support] "in a customer application"? This sounds
like a general refusal to use code written by "someone else" (and in this
case, "someone else" is Digital -- us).

	/dave

What DECthreads does is fairly simple.  "Periodically", it gets the current
time from the system and checks the list of waiting threads to see if any
timeouts have expired.  This check is performed by a housecleaning thread
which we call the "manager" thread.  When there is no other work for the
manager thread to do, it blocks in a synchronous system call until the time
when the next waiting thread needs to wake up.

Thus, there are no signals involed -- everything is done synchronously.
There's no mmap'ing (although that is something we are considering doing for
other reasons, but that's a tiny efficiency concern).  It's all done with
basic, synchronous, threaded programing.  (Yes, even DECthreads is
multithreaded... :-)

Since your package already uses threads, there is no reason to use signals.
Using sigwait() is the best way to interface threads and signals, but if you
can avoid using signals altogether, I think you'll be better off!



				Webb

    Dave, sorry the "in general I don't prefer using this..." was
    a bug in my internal translation machine. As I'm clearly no native 
    english speaker, in general, I'm translating in first floor and 
    my hands in second floor are typing.
    My intention was to express that I don't want to mmap the OS timers
    in user land in code I supply to partners (except benchmark situation)
    We could do this as we're using two device drivers. 
    I meant that I would prefer those kind being implemented in a Digital
    owned library. sorry, when I red it, I knew it wasn't that clear, 
    and here's what I wanted to say.
    
    sorry && thanks,
     Pit          

    .2 thanks too. I'm trying to rid get of as many signals as possible, 
    that's why I asked. Currently when I've recoded the delay handling 
    we've still one left.
    This is due to the fact, that we still use our own asynch I/O driver.
    Ok, I could use diffrent synchronization between user and kernelland,
    but as we have already recoded it to use the OS supplied AIO mechanism
    we will stick around with the asynch I/O notification via signals,
    which works fine (currently it's some internal limitiation which 
    delay's enabling this until V4.0C).
    
    I understand your current implementation a bit like the callout
    mechanism. I thought of setting my timer thread to a higher 
    prio to enable being selected as first choice thread. Do the 
    delay implication of the callout queue apply to your model too,
    and what could be maximum "negative" delay. (or is this neglectable).
    
    Pit 

.4>     I understand your current implementation a bit like the callout
.4>     mechanism. I thought of setting my timer thread to a higher 
.4>     prio to enable being selected as first choice thread. Do the 
.4>     delay implication of the callout queue apply to your model too,
.4>     and what could be maximum "negative" delay. (or is this neglectable).

I'm not sure I understand what you are suggesting here, Pit.

You are free to set your timer thread to a higher priority if you like.  When
its timeout expires it will preempt the running thread, if the timer thread
has a preemptive scheduling policy and if its priority is higher than the
priority of the currently running thread.  Otherwise, the normal scheduling
rules apply -- that is, the thread scheduler will select the highest priority
thread to run next.  If there are lots of ready threads at the same or higher
priority, the timedwait thread many spend extra time sitting on the ready
queue before it gets to run.  (Is this what you mean by "'negative' delay"?)


					Webb

    currently, I've got the working threads running on equal prio.
    as the dealy structure is vital for our implementaion, I would 
    increase it's prio to achieve the behaviour, you've depicted nicely 
    in .-1. 
    the callout mechanism in the operating system, " puh let me find the
    right wording", it's a queue with action(function) pointers chained
    in order of time due. it gets scanned by the softclock algorithm.
    and if the time field is <= 0 (a bit simplified). the required action
    gets invoked. as softclock gets called via hardclock and also performs
    different tasks, it can happens that the time field gets negative
    due to other/higher system tasks. That's what I meant with negative
    delay. Better :-)
    
    Pit 

.6> That's what I meant with negative delay. Better :-)

Yes, that's better.

You face the same sort of issues with timedwait.  Due to other activity on the
system, the timedwait thread may not get readied exactly on time (i.e., if your
process's priority is too low or the system is too busy).  Due to other activity
in your process, the timedwait thread may not get to run exactly on time (i.e.,
if the thread's priority is too low or there are lots of other runnable threads
at the same priority).  Of course using signals doesn't help with any of these.


				Webb

    You can always use usleep in libc or nanosleep in librt. No signals
    involved and no involvement with the DECthreads "delay" thread
    either. And if you run as a system scope thread on V4.0D (ptmin),
    you'll get good response for your high-prio thread.