comp.lang.ada
 help / color / mirror / Atom feed
* process blocking
@ 2004-09-09  7:49 P Hull
  2004-09-09 11:38 ` Stephen Leake
  2004-09-10  3:07 ` Steve
  0 siblings, 2 replies; 6+ messages in thread
From: P Hull @ 2004-09-09  7:49 UTC (permalink / raw)


Hi, I know this is possible, but how does one go about having a process (p1)
siezing control of another process (pMain) such that no other process (p2,
p3, .. pn) is able to access pMain? I am guessing you define one channel and
maintain access to this channel? I have no idea how to implement such
blocking.

any help most appreciated

thanks
peter





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: process blocking
  2004-09-09  7:49 process blocking P Hull
@ 2004-09-09 11:38 ` Stephen Leake
  2004-09-09 11:50   ` P Hull
  2004-09-10  3:07 ` Steve
  1 sibling, 1 reply; 6+ messages in thread
From: Stephen Leake @ 2004-09-09 11:38 UTC (permalink / raw)
  To: comp.lang.ada

"P Hull" <p.hull@msw.com> writes:

> Hi, I know this is possible, but how does one go about having a process (p1)
> siezing control of another process (pMain) such that no other process (p2,
> p3, .. pn) is able to access pMain? I am guessing you define one channel and
> maintain access to this channel? I have no idea how to implement such
> blocking.

If you can use an Ada task for your "process", and by "access" you
mean "rendezvous with", then this is a matter of visibility; make sure
task pMain is only visible to task p1. Declaring pMain in a private
child of the package that declares p1 is one way to do this.

However, that is a static solution. If you need to change which tasks
are able to rendezvous with pMain at run time, you'll need a different
mechanism.

If you explain more about why you think you need to do this, there is
probably another way to accomplish it. 

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: process blocking
  2004-09-09 11:38 ` Stephen Leake
@ 2004-09-09 11:50   ` P Hull
  2004-09-09 14:51     ` Georg Bauhaus
  2004-09-09 18:09     ` Ludovic Brenta
  0 siblings, 2 replies; 6+ messages in thread
From: P Hull @ 2004-09-09 11:50 UTC (permalink / raw)


> > Hi, I know this is possible, but how does one go about having a process
(p1)
> > siezing control of another process (pMain) such that no other process
(p2,
> > p3, .. pn) is able to access pMain? I am guessing you define one channel
and
> > maintain access to this channel? I have no idea how to implement such
> > blocking.
>
> If you can use an Ada task for your "process", and by "access" you
> mean "rendezvous with", then this is a matter of visibility; make sure
> task pMain is only visible to task p1. Declaring pMain in a private
> child of the package that declares p1 is one way to do this.
>
> However, that is a static solution. If you need to change which tasks
> are able to rendezvous with pMain at run time, you'll need a different
> mechanism.
>
> If you explain more about why you think you need to do this, there is
> probably another way to accomplish it.

Hi thanks for the reply.

Oh i was not looking for a static solution. pMain is visible to all tasks
p1..pn. The first task (i.e. one of p1..pn based upon some timing mechanism)
will rendezvous with pMain and seizes pMain. And once pi has finished
whatever it wants to do with pMain, some other task within p1..pn will then
next rendezvous with pMain and seize it, and once finished .. etc etc

I know this should be simple to implement. Thanks for any help

Peter





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: process blocking
  2004-09-09 11:50   ` P Hull
@ 2004-09-09 14:51     ` Georg Bauhaus
  2004-09-09 18:09     ` Ludovic Brenta
  1 sibling, 0 replies; 6+ messages in thread
From: Georg Bauhaus @ 2004-09-09 14:51 UTC (permalink / raw)


P Hull <p.hull@msw.com> wrote:
 
: Oh i was not looking for a static solution. pMain is visible to all tasks
: p1..pn. The first task (i.e. one of p1..pn based upon some timing mechanism)
: will rendezvous with pMain and seizes pMain. And once pi has finished
: whatever it wants to do with pMain, some other task within p1..pn will then
: next rendezvous with pMain and seize it, and once finished .. etc etc

is pMail special so that you could hide it behind a protected object?


-- georg



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: process blocking
  2004-09-09 11:50   ` P Hull
  2004-09-09 14:51     ` Georg Bauhaus
@ 2004-09-09 18:09     ` Ludovic Brenta
  1 sibling, 0 replies; 6+ messages in thread
From: Ludovic Brenta @ 2004-09-09 18:09 UTC (permalink / raw)


"P Hull" writes:
> Oh i was not looking for a static solution. pMain is visible to all
> tasks p1..pn. The first task (i.e. one of p1..pn based upon some
> timing mechanism) will rendezvous with pMain and seizes pMain. And
> once pi has finished whatever it wants to do with pMain, some other
> task within p1..pn will then next rendezvous with pMain and seize
> it, and once finished .. etc etc
>
> I know this should be simple to implement. Thanks for any help

Why does pMain have to be a task?  Could it not be a protected object
instead?  Then, the task pi would call a procedure or entry in the
protected object.  While that procedure or entry is executing, other
tasks that also want to execute a procedure or entry in pMain must
wait.

Here is an example:

protected pMain is
   procedure Seize_And_Do_Whatever;
private
   Protected_Data : Integer;
end pMain;

protected body pMain is
   procedure Seize_And_Do_Whatever is
   begin
      Protected_Data := 42;
   end Seize_And_Do_Whatever;
end pMain;

Now, any task pi can call pMain.Seize_And_Do_Whatever.  The processing
takes place in the task pi; pi is not blocked.  If another task, pj,
wants to call pMain.Seize_And_Do_Whatever, it waits.

See the reference manual section 9.4 for more details.

[1] http://www.adaic.org/standards/ada95.html
[2] http://www.adaic.org/standards/95lrm/html/RM-9-4.html

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: process blocking
  2004-09-09  7:49 process blocking P Hull
  2004-09-09 11:38 ` Stephen Leake
@ 2004-09-10  3:07 ` Steve
  1 sibling, 0 replies; 6+ messages in thread
From: Steve @ 2004-09-10  3:07 UTC (permalink / raw)


In kinda pseudo-code form:

  If you set up the main process pMain with a loop, something like:

  task pMain is
  begin
    loop
      accept Step1;
      ... some code ...
      accept Step2;
    end loop;
  end pMain;

  Then have the process p1 rendevous with the two in sequence:

    myTask.Step1;
   ... some code ...
    myTask.Step2;

  You should get the described behaviour.

Steve
(The Duck)

"P Hull" <p.hull@msw.com> wrote in message
news:41400af9$1@dnews.tpgi.com.au...
> Hi, I know this is possible, but how does one go about having a process
(p1)
> siezing control of another process (pMain) such that no other process (p2,
> p3, .. pn) is able to access pMain? I am guessing you define one channel
and
> maintain access to this channel? I have no idea how to implement such
> blocking.
>
> any help most appreciated
>
> thanks
> peter
>
>





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-09-10  3:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-09  7:49 process blocking P Hull
2004-09-09 11:38 ` Stephen Leake
2004-09-09 11:50   ` P Hull
2004-09-09 14:51     ` Georg Bauhaus
2004-09-09 18:09     ` Ludovic Brenta
2004-09-10  3:07 ` Steve

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox