On Tue, Mar 07, 2006 at 10:13:42PM -0000, jerrywrice_fabnexus wrote:
> Lennert,
Hello,
> 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.
Right. Under Windows, it's safe to call CloseHandle() on a mutex that
is in use, because it does internal refcounting. You can do the same
in linux, and keep a reference count by hand. Start with a refcount
of 1, +1 it every time it gets locked successfully, -1 it every time
it gets released, and -1 it when the final destroy is called. When
it drops to zero, only then free it..
However, it's probably faster if you can rework your code so that
you can be sure that noone is using a certain mutex anymore..
> 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);
> }
That's not safe, what if another thread does:
pthread_mutex_lock(&mut);
while (variable != 42)
pthread_cond_wait(&cond, &mut);
pthread_mutex_unlock(&mut);
You're never going to get that thread out of its loop unless you kill
it or set variable to 42.
> 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.
You can just block those signals?
> It is for these reasons that I'm entertaining the idea of using
> the RTAI "real-time" extensions.
As another poster has said, I'm not quite sure how using a "real time"
OS will solve these issues?
The problem here seems to be mostly an impedance mismatch in the use/
expectations of synchronisation primitives, if there is an RTOS where
the available primitives do map nicely to your abstraction layer it's
just because that the available primitives are different, and not
specifically because they had "RT" in mind..
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/
|