pthread_cancel()

Pattara Kiatisevi pkiatisevi at student.ei.uni-stuttgart.de
Wed Mar 13 12:52:38 UTC 2002


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?

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? :)

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




More information about the users mailing list