Thanks Jim and Lennert, I understand and accept your points. I am a
Linux newbie, and your input is appreciated and helpful. JR
--- In Jim Jackson <> wrote:
>
>
> 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 <buytenh@>
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/
|