Lennert,
Thanks for your interest. We are porting our application
communications library (written in C)from Windows. We've written an
abstract OS layer which consists of a set of primitives whose
function-bodies are re-implemented for each platform.
The application consist of a single-process multi-threaded
package. Included in our virtual OS primitive set, for example, is a
thread synchronization primitive "MutexWait()" function that takes
a "maximum wait timeout" parameter. Under Windows this is implemnted
with the "WaitForSingleObj(mutex,1000);" which means "wait for this
mutex to be available for upto 1000 ms, and timeout if not available".
In the Linux environment we plan on using the Linux pthread
library, including the "pthread_cond_timedwait()" feature coupled
with a pthread_mutex for atomic protection (per standard pthread
library practice).
One specific problem is that when any application thread
indirectly invokes "pthread_cond_destroy()" to deallocate the
semaphore resource, it is documented that the results are "unknown"
if another application thread is currently using (waiting on) that
condition-variable. The literature indicates the following code
sequence can be used to "safely" deallocate the pthread_cond object.
/* Destroy/dealloate an inited pthread_cond_t. */
{
int rc;
rc = pthread_mutex_lock(&mut);
rc = pthread_cond_broadcast(&cond);
rc = pthread_mutex_unlock(&mut);
L2:
rc = pthread_cond_destroy(&cond);
rc = pthread_mutex_destroy(&mut);
}
It appears to us that within a busy multi-threaded application
that there is a potential problem time-window between when the mutex
is unlocked (L2) and the condition-var is destroyed, within which
another thread may reference/use the condition-variable.
This is one example of the issues we're running into. Another is
a performance-related issue. It seems that
the "pthread_cond_timedwait()" prematurely wakes-up every time an
interrupt signal is generated. While this doesn't prevent the
application from functioning correctly, it certainly seems
inefficient. Since our application may be running a number of
simulteneous TCP-IP channels (sockets), performance is potentially an
issue.
There are a number of other issues that have surfaced similar to
these.
It is for these reasons that I'm entertaining the idea of using
the RTAI "real-time" extensions.
JR
--- In Lennert Buytenhek <> wrote:
>
> On Mon, Mar 06, 2006 at 10:57:14PM -0000, jerrywrice_fabnexus wrote:
>
> > We are porting our existing communications product software
(written
> > in C) from Windows to Linux, and are running into a number of
> > limitations with the standard Linux thread manipulation and
critical
> > region features (primarily pthreads and the System V 'sem'
operations).
>
> If you can share what problems you are having, maybe we can fix
those
> problems..
>
>
> cheers,
> Lennert
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|