[oggonachip] Re: pthread_cancel()

[Jake Janovetz]

I kind of see this stuff whizzing before my eyes for the last couple days
and I realize that you're talking about an Ogg player on RTEMS.  I've got a
substantial amount of code written for something similar under RTEMS (MP3
player).  I think it may be useful.  Who knows.  In any case,
www.janovetz.com/cantante has a description of the project.

The code I have is for a server (Linux-based) that keeps a database of MP3s
and serves them up, a device (RTEMS) for playing them, a Java applet for
controlling the device, and a PalmOS applet for controlling the device.

If anyone is interested, let me know.

   Jake


----- Original Message -----
From: "Pattara Kiatisevi" <pkiatisevi at student.ei.uni-stuttgart.de>
To: <oggonachip at yahoogroups.com>
Cc: "'RTEMS Users'" <rtems-users at oarcorp.com>
Sent: Tuesday, April 16, 2002 5:29 PM
Subject: Re: [oggonachip] Re: pthread_cancel()


> On Thu, 14 Mar 2002, Aaron J. Grier wrote:
>
> > On Thu, Mar 14, 2002 at 11:14:05AM +0100, Pattara Kiatisevi wrote:
> >
> > > 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>
> >
> > use a simple binary semaphore.
>
> Hmm, but in case that task2 is faster than task1, then it released while
> noone was waiting (for obtaining). And then task1 blocks later, waiting
> for task2 to release whenever later. So it does not really correspond to
> the above rendezvous scheme? (whoever who is faster will wait for another
> one and go together). Do I miss sth?
>
> Thanks,
> Pattara
>
> >
> > rtems_id semaphore;
> > rtems_name semaphore_name;
> >
> > status = rtems_semaphore_create(
> >     semaphore_name,
> >     0,
> >     RTEMS_SIMPLE_BINARY_SEMAPHORE,
> >     RTEMS_NO_PRIORITY,
> >     &semaphore
> > );
> >
> > task 1: task 2:
> >
> > <run whatever> <run whatever>
> >
> > rtems_semaphore_obtain( <still running>
> >     semaphore,
> >     RTEMS_WAIT,
> >     RTEMS_NO_TIMEOUT
> > );
> >
> > <blocked> <still running>
> >
> > rtems_semaphore_release(
> >     semaphore
> > );
> >
> > <starts running> <continues on>
> >
> > in this case task2 continues to run regardless of whether or not task1
> > is blocked.  it is completely up to task1 to complete its work before
> > task2 performs another release().  (task2 could tell whether or not
> > task1 was blocking by checking the return status of the release() call.)
> >
> > I use this system in my audio device driver.  :)  "task 2" in my case is
> > an ISR which moves buffer data to and from the sound card, and "task 1"
> > is the read() and write() calls of the device driver.
> >
> > --
> >   Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com
> >      "In a few thousand years people will be scratching their heads
> >        wondering how on earth the first computer was invented and
> >           bootstrapped without a prior computer to do it with."
> >                     --  Chris Malcolm, on comp.arch
> >
> > ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> > Tiny Wireless Camera under $80!
> > Order Now! FREE VCR Commander!
> > Click Here - Only 1 Day Left!
> > http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/gWFolB/TM
> > ---------------------------------------------------------------------~->
> >
> > To unsubscribe from this group, send an email to:
> > oggonachip-unsubscribe at yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
>