pthread_cancel()

Pattara Kiatisevi pkiatisevi at student.ei.uni-stuttgart.de
Thu Mar 14 10:14:05 UTC 2002


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

Is there concept of rendezvous in classsic API? E.g. how would you
implement this scenario? (It is not certain that task1 will connect to
task2.meet() before or after task2 is waiting at task2.meet())

Task 1:				Task2:

<run whatever>			<run whatever>

Connect task2.meet() ----------> Wait task2.meet()
				 <meeting point code, run while task1
				  blocks>

<run whatever>			<run whatever>

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

We are using FPU but there is Intergerized version of Vorbis available now
(although not yet compilable), we will have a look in it as soon as
possible)

BTW, seems that default config = non-floating point? I have to manually
add:
#define CONFIGURE_INIT_TASK_ATTRIBUTES (RTEMS_FLOATING_POINT |
RTEMS_DEFAULT_ATTRIBUTES)

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

We neither have any modifications to RTEMS nor Ogg/Vorbis (or maybe not
yet). The main task of our project is to do hardware/software partitioning
(because only software is not fast enough to run on limited-resource
hardware). Now the player code just runs on RTEMS/LEON a few days ago
(utilizing RTEMS POSIX Thread interface + my own device drivers for Sound
hardware -- as you might have guessed from my past questions to the list)
so that real task of software/hardware partitioning has just really begun
:).

For the application code (that uses RTEMS), I would be more than happy if
you want to get it included in RTEMS as example applications or so. If
that case, at the end of project (hopefully in May or June) after clean up
and having nice build instructions (now it is a bit mess) then I will
submit it to you. Just let me know.

Regards,
Pattara

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