Jerry,
Given there are very many multithreaded applications (which no doubt have
similar constraints to yours) written for Linux, have you looked at how
other applications handle this problem - after all you most come with
source code. Also this is not a specific problem to this board but a
general problem for any (2.4) linux system, so have you tried more
appropriate email lists/groups where multi-threading linux experts will be
found?
Maybe I'm being excessively stupid here, but I don't necessarily see what
using an RTOS gives you here - it does look like a RT related problem you
are describing, but I'm sure you'll correct me there.
Also "single-application multi-threaded" in the 2.4 linux world is a bit
of an oxymoron - "single-program multi-threaded" might be more accurate.
In linux, on the whole, a thread is a process which shares attributes
(mapped memory e.g.) with other related processes.
A colleague tells me that using the POSIX thread library gives maximum
portability across platforms, well "unix" ones at least.
cheers
Jim
On Tue, 7 Mar 2006, jerrywrice_fabnexus wrote:
> 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
>
>
>
>
>
>
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/
|