thread-specific timeouts

thread-specific timeouts

Post by Kemal Oral » Mon, 25 Oct 2004 04:47:37


Hi all,

I am fairly new to posix threads. I would like to ask the best way to handle
thread-specific timeouts in a multithreaded application with event queues.
Do we have to do alot of bookkeeping to accomplish this, or is there any
tricky way to do it? I am really in need of an answer. Also, is there any
way to do select() on timeouts?

Thank you very much,

-Kemal.
 
 
 

thread-specific timeouts

Post by loic-de » Sun, 31 Oct 2004 21:04:02

Hello Kemal,


Assuming that your event queue is programmed used condition variable
(CV), the best solution would be then to used a timed wait on the CV,
see /pthread_cond_timedwait()/.

HTH,
Loic.

 
 
 

thread-specific timeouts

Post by Kemal Oral » Wed, 03 Nov 2004 12:38:38

Thanks for the reply,

I think I have to rephrase my question. I was looking for a way to provide a
general timeout mechanism at thread level. For instance, a thread would
register for a timeout (just like processes do with alarm() ), continues its
execution, and when timeout occurs, it will be signaled by some way and
handle the timeout. I am looking for a simple, well-established method to
realize this behaviour. Do I have to do it like the software timers work
keeping a priority queue? Any other ways?

With many thanks,

-Kemal.
 
 
 

thread-specific timeouts

Post by Joe Seig » Wed, 03 Nov 2004 19:28:10


What exactly will your thread do when it receives a "timeout" signal?
Just exit with data and locks in indeterminate state?

Joe Seigh
 
 
 

thread-specific timeouts

Post by Kemal Oral » Wed, 03 Nov 2004 21:17:06

Hi,

When a timeout signal is received, I want my thread to update some data
structures, and do some calculation pertinent to the type of the timeout;
i.e. complex processing. There will be multiple types of timeouts, and the
behavior of the thread would change according to the characteristics of
timeouts. Specifically, I am programming a network node that handles various
application level protocol messages and each type of message has different
timeouts to act upon. The node is inherently multi-threaded, each thread is
responsible for communication with another node. I hope this makes clear. It
is a design problem, and just wanted to hear opinions from experienced
developers.

Thank you,

-Kemal.
 
 
 

thread-specific timeouts

Post by Joe Seig » Wed, 03 Nov 2004 21:40:19


Well, don't use signals. They're way too problematic even for experienced programmers.
The standard way of using timeouts is to use pthread_cond_timedwait() or select()/poll()
depending on what you are doing. That's a lot of work but writing a program and signal
handler that works correctly when interrupted at an arbitrary point of execution is
even more work.

Joe Seigh
 
 
 

thread-specific timeouts

Post by Sean Burk » Sun, 07 Nov 2004 10:39:19


Joe Seigh < XXXX@XXXXX.COM > writes:



Here's a thought, which I have not put in practice, but which seems to have
advantages for the OP's purpose. Each thread should open a pipe, that it will
use to receive timeout messages. Make it nonblocking, so that your thread can
check for timeout events in between blocking operations. When doing a blocking
operation, such as connect or a socket read, use select/poll, and the include
the readable fd of the pipe in the fd set, so that the select/poll call will be
awakened upon a timeout. You will also need a separate timer thread to issue
timeout events. When a timeout expires, it simply writes a record to the pipe
associated with the thread that registered the timeout.

The Nifty library contains a timer queue implementation that could be used as
a basis for this mechanism. Check out nft_task.c in

ftp://ftp.xenadyne.com/pub/Nifty.tgz

-SEan
 
 
 

thread-specific timeouts

Post by Kemal Oral » Tue, 09 Nov 2004 15:03:28

Thank you all,

Sean, I just implemented something similar to your proposal. Specifically,
one thread checking for its event queue (events including the timeout) and
acting according to the type of event, and the other receiving messages from
TCP connection, also posting events back to the event queue of the main
thread. The businness logic is captured within the main thread. There is a
single timer thread, which ticks every X secs (whose resolution could be
parameterized) and broadcasts every tick to all stub threads (the threads
that communicate with neighbor nodes and each having seperate event queue);
something like emulating the actual hardware clock, but it does the job for
me.

Regards,

-Kemal.