ts-7000
[Top] [All Lists]

Re: [ts-7000] Re: has anyone used the ADEOS and RTAI on TS-7250

To:
Subject: Re: [ts-7000] Re: has anyone used the ADEOS and RTAI on TS-7250
From: Jim Jackson <>
Date: Wed, 8 Mar 2006 11:48:15 +0000 (GMT)


On Wed, 8 Mar 2006, 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

sorry I meant to say "...it does NOT look like a RT related problem..."

> 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
>
>
>
>
>
>
>


 
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/
 


<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU