pthread_cancel()
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Mar 13 18:19:22 UTC 2002
Pattara Kiatisevi wrote:
>
> ok, thank you very much.
>
> BTW, now I have the Ogg/Vorbis player running on RTEMS(+PThread)/TSIM.
> Normal. I use PThread because the documentation and people to consult are
> there. However, will the performance be better (considering this task
> communication/synchronization aspects) when using rtemstask instead of
> pthread?
The RTEMS Classic, POSIX, and ITRON APIs are all implemented in terms
of the same core services and generally have the same execution
characteristics. For example, all counting semaphores -- regardless
of API -- are wrappers for the SuperCore object "Semaphore". Ditto
for mutexes and message queues.
With that said, POSIX and the Classic API each have features not in the
other. For example, the Classic API has "timers" which are basically
scheduled subroutines. This is really nothing comparable in POSIX.
So if you are using POSIX services with no counterpart in the Classic
API, there is no alternative.
One feature available to Classic threads which MIGHT matter to you
is the ability to create an "non-floating point" task. This task
does not have a FP context to save/restore and, if possible, the
port specific code will disable the FPU to prevent FP operations.
This can speed up context switches if you can take advantage of it.
But somehow I suspect you are using the FPU.
> And what I found is that my 10-lines of code using Ada's SELECT became
> >50 lines of this pthread_cond_*/pthread_mutex_* stuff. It is a bit ugly,
> if I use rtemstask instead of pthread, will there be something nicier? :)
There is nothing like condition variables in the Classic API. So this
is a case where there isn't an alternative to switch to.
Another alternative is to send messages and wait on a queue but that
might not be a good fit either.
How can we get your work included in the appropriate places in
the two projects? Are there modifications to Ogg/Vorbis to submit?
Do they care? Did you have to do anything to RTEMS? Do you
have build instructions?
> Thanks,
> Pattara
>
> --
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.fsf.org/philosophy/no-word-attachments.html
> ----------------------------------------------------------------------
> Ott Pattara Kiatisevi T L W G
> M.Sc. INFOTECH Student, Stuttgart, Germany http://linux.thai.net/
> ----------------------------------------------------------------------
>
> On Wed, 13 Mar 2002, Joel Sherrill wrote:
>
> >
> >
> > Pattara Kiatisevi wrote:
> > >
> > > Hi,
> > >
> > > You mean RTEMS is implemented according to POSIX but they work not in the
> > > same way? I'm not sure I understand all what you said. It is a bit
> > > complex.
> >
> > Not exactly. I said RTEMS initially implemented a subset of a DRAFT of
> > the POSIX standard. Any changes from that draft to the final
> > approved version might not be reflected. Also I am sure cancellation
> > is one of those things that GNU Ada did not require so there was no
> > driving
> > force to ensure it worked. The shell of an implementation is there
> > as best I can tell.
> >
> >
> > > Anyway, I read from O'Rielly Pthread Programming book and tried to make it
> > > work with RTEMS but not successful. Every methods mentioned in the book
> > > work on Linux but not RTEMS so how exactly to use pthread_cancel() in
> > > RTEMS? :) Attached is my test program that works fine on Linux and
> > > utilized both DEFERRED and ASYNCHRONOUS method.
> >
> > OK. I have been out of town and will have to file an RTEMS PR to track
> > this with. I have pressing deadlines this week.
> >
> > > Regards,
> > > Pattara
> > >
> > > On Sat, 9 Mar 2002, Joel Sherrill wrote:
> > >
> > > > I have been thinking more and it really isn't as bad as I
> > > > made it out to be.
> > > >
> > > > Joel Sherrill wrote:
> > > > >
> > > > > Pattara Kiatisevi wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Is pthread_cancel working fine with RTEMS? It doesn't seem to cancel :)
> > > > > > I also can't find it here:
> > > > > > http://www.oarcorp.com/rtemsdoc-4.5.1-pre3/rtemsdoc/html/posix_users/posix_users00326.html
> > > > >
> > > > > It is there but my reading is that it doesn't work like the Linux man
> > > > > page.
> > > >
> > > > There is a man page although it is basically a shell. POSIX called this
> > > > Thread Cancellation and made it a separate chapter. This is why the
> > > > manual has an index. :)
> > > >
> > > > http://www.oarcorp.com/rtemsdoc-4.5.1-pre3/rtemsdoc/html/posix_users/posix_users00362.html
> > > >
> > > > > And the Linux man page does not look anything like the functionality
> > > > > that
> > > > > was in the draft spec this was originally implemented against. Based
> > > > > upon
> > > > > the Linux man page, I would tend to treat this as a special test in
> > > > > the calls listed on the Linux man page.
> > > >
> > > > And I still tend to think that's the right way to go. And I think
> > > > the RTEMS implementation is mostly there.
> > > >
> > > > > I am sorry to say this but the semantics of the RTEMS implementation
> > > > > do not appear to be what any modern program using them would expect.
> > > > >
> > > > > This raises the question.. how critical are they to the app you are
> > > > > porting? If they are important, would you be willing (with advice/help)
> > > > > to fix the implementation?
> > > >
> > > > I will make you an offer. I will file a PR to track this with. You
> > > > start
> > > > by writing some test programs that fully exercise the functionality of
> > > > the cancelation manager. These should work on Linux and I will adapt
> > > > the
> > > > configurery to RTEMS. That should really be enough to identify what's
> > > > deficient.
> > > >
> > > > Then identify precisely the points in the FSU and Linux pthreads
> > > > implementation where a cancellation actually occurs inside the
> > > > services listed. Submit those and let me review what's broken. I
> > > > suspect that fixing it is not really hard and mostly a matter of
> > > > inserting
> > > > a cancellation test at the right point in pthread_join, sigwait, etc.
> > > >
> > > > And while I am fixing it, you can fill in the manager documentation
> > > > since
> > > > you will actually understand it then. :)
> > > >
> > > > As an aside, I also remember that condition variables and cancellation
> > > > were
> > > > very difficult to figure out how they really worked in the draft POSIX
> > > > specification we implemented against. And cancellation points were not
> > > > required to make the GNU Ada run-time work which is why we initially
> > > > implemented POSIX threads. This is not a defense of their status, only
> > > > some background.
> > > >
> > > > > > Thanks,
> > > > > > Pattara
> > > > > >
> > > > > > --
> > > > > > Please avoid sending me Word or PowerPoint attachments.
> > > > > > See http://www.fsf.org/philosophy/no-word-attachments.html
> > > > > > ----------------------------------------------------------------------
> > > > > > Ott Pattara Kiatisevi T L W G
> > > > > > M.Sc. INFOTECH Student, Stuttgart, Germany http://linux.thai.net/
> > > > > > ----------------------------------------------------------------------
> > > > >
> > > > > --
> > > > > Joel Sherrill, Ph.D. Director of Research & Development
> > > > > joel at OARcorp.com On-Line Applications Research
> > > > > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> > > > > Support Available (256) 722-9985
> > > >
> > > > --
> > > > Joel Sherrill, Ph.D. Director of Research & Development
> > > > joel at OARcorp.com On-Line Applications Research
> > > > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> > > > Support Available (256) 722-9985
> > > >
> > > >
> > >
> > > ------------------------------------------------------------------------
> > > Name: testthread.c
> > > testthread.c Type: TEXT/x-csrc
> > > Encoding: BASE64
> >
> > --
> > Joel Sherrill, Ph.D. Director of Research & Development
> > joel at OARcorp.com On-Line Applications Research
> > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> > Support Available (256) 722-9985
> >
> >
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list