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