«

I've done several searches but can't find anything really specific to
what I'm doing. This is the first program I have ever used threads
with.

The program talks to a serial port with standard Linux read/write
function calls. However, those are blocking calls, like the read, it
will block until there is something to read. I don't want a broken
link to stop the whole program, so I'm using threads. I have a modbus
thread and a logic thread. The modbus thread does the actual
reading/writing on the serial port and updates a global array of values
(using the mutex lock/unlock method, so data integrity is protected).
However I would like the read/write functions to basically be in their
own thread also (a 'small' thread perhaps, with only that function?),
that I could time out. So I could say if the ReadMBThread didn't
complete in 100ms I would terminate it and log and error and go on.

I have not found anything specific about timing a thread like that. I
read up on the TimedWait where you're either waiting on a condition or
mutex to become free. I guess I could rig the code up with that, so
technically it would be waiting on a mutex, but not really since it's
really just waiting on the read/write function to complete, but I could
have some mutexs to solve that probably.

Any ideas? Can you put a timeout on a thread when you create it?

Thanks in advance!
Mark Brodis
(E-Mail Removed)

In article <(E-Mail Removed) .com>,
(E-Mail Removed) wrote:

> So I could say if the ReadMBThread didn't complete in 100ms I would
> terminate it and log and error and go on.

You can use pthread_cond_timedwait() to wait for a condition variable
to be signaled, or else time out. There's a tricky part, though - a
condvar doesn't 'remember' that it's been set, and if you're not
careful you can 'lose' a signal. Here's roughly what I use:

typedef struct delay_object {
int guard; /* pthread_cond_signal() does not record signals. If no
threads are waiting on a cond variable and the cond is
signaled, nothing happens. So to avoid race conditions,
we need this guard variable to record the fact that the
thread should not try to delay. */
pthread_mutex_t mutex;
pthread_cond_t cond;
} DELAY_OBJECT;

/* Wait for the specified number of seconds. If we time
out, return -1, but if we are woken early, return 0. */
int Thread_Delay(DELAY_OBJECT *delay_obj, int seconds)
{
int rc;
struct timeval now;
struct timespec wait;

pthread_mutex_lock(&delay_obj->mutex);
if (delay_obj->guard) { /* Should we bother delaying? */
rc = 0; /* tell calling thread we woke early. */
} else {
delay_obj->guard = 1; /* Mark that we are delaying. */
gettimeofday(&now, NULL);

memset(&wait, 0, sizeof(wait)); /* ensure it's initialized */
wait.tv_sec = now.tv_sec + seconds;

if (ETIMEDOUT == pthread_cond_timedwait(&delay_obj->cond,
&delay_obj->mutex,
&wait)) {
rc = -1; /* timeout */
} else {
rc = 0; /* someone woke us up */
}
}
delay_obj->guard = 0; /* Out of delay. */
pthread_mutex_unlock(&delay_obj->mutex);
return rc;
}

/* Wake up a thread that's sleeping. */
int Wake_Thread(DELAY_OBJECT *delay_obj)
{
pthread_mutex_lock(&delay_obj->mutex);
if (delay_obj->guard) {
pthread_cond_signal(&delay_obj->cond); /* Wake thread from sleep. */
} else {
delay_obj->guard = 1; /* Thread not sleeping now, tell it not to try. */
}
pthread_mutex_unlock(&delay_obj->mutex);
}

Your read thread can wait on the "delay object" and, if it's not woken
up, time out and return. You I/O thread can send a wakeup signal to the
read thread when data comes in. If you need more help, you might want
to ask on comp.programming.threads.

--
Sincerely,

Ray Ingles (313) 227-2317

"...it's not a plain, ordinary steel nut: it's a 'hexiform rotatable
surface compression unit', which is why it cost $2,043 for just
one..." - William Lutz, on Pentagonese, in _Doublespeak_

Hi,

if your thread is listening on the in a blocking fashion, it will do that
till it receives a signal or data (same thing for listening on a socket).
So you can use the main thread to check every once in a while wheather it
is necessary to "kill" the listening thread, and if so, send a signal.

With kind reagards, Alex


(E-Mail Removed) wrote:

> I've done several searches but can't find anything really specific to
> what I'm doing. This is the first program I have ever used threads
> with.
>
> The program talks to a serial port with standard Linux read/write
> function calls. However, those are blocking calls, like the read, it
> will block until there is something to read. I don't want a broken
> link to stop the whole program, so I'm using threads. I have a modbus
> thread and a logic thread. The modbus thread does the actual
> reading/writing on the serial port and updates a global array of values
> (using the mutex lock/unlock method, so data integrity is protected).
> However I would like the read/write functions to basically be in their
> own thread also (a 'small' thread perhaps, with only that function?),
> that I could time out. So I could say if the ReadMBThread didn't
> complete in 100ms I would terminate it and log and error and go on.
>
> I have not found anything specific about timing a thread like that. I
> read up on the TimedWait where you're either waiting on a condition or
> mutex to become free. I guess I could rig the code up with that, so
> technically it would be waiting on a mutex, but not really since it's
> really just waiting on the read/write function to complete, but I could
> have some mutexs to solve that probably.
>
> Any ideas? Can you put a timeout on a thread when you create it?
>
> Thanks in advance!
> Mark Brodis
> (E-Mail Removed)