pthread_cancel()

Aaron J. Grier aaron at frye.com
Thu Mar 14 23:28:45 UTC 2002


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.

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



More information about the users mailing list