Imported Monolitic Monitor

Imported Monolitic Monitor

[Juan Carlos Díaz Martín]

Let's be the C procedures in a module that share global data

 a
 b
 c

and I make a C library with them. This library will be used by a
multitasked Ada95 application by the pragma Import

Tasks T, Q and R may invoke a, b or c in a concurrent, uncontrolled way.
Isn't it? I'm interested in a, b and c to be executed in mutual
exclusion to preserve global data integrity. The question is: How do I
do it in Ada95?
I've thought in a protected object, such as:

protected Monitor is
  procedure a;
  procedure b;
  procedure c;
end Monitor;

The object could be used:

with Monitor;
procedure P is
begin
  ...
  a; b; c;
  ...
end P;

task T is      task Q is     task R is
begin          begin         begin
  P;             P;            P;
end;           end;          end;

Does this way guarantee mutual exclusion of a, b and c??? Any ideas??

Thanks in advance
Juan Carlos

Re: Imported Monolitic Monitor

[dennison]

In article <36E014CD.55717933@unex.es>,
  "Juan Carlos =?iso-8859-1?Q?D=EDaz=20Mart=EDn?=" <juancarl@unex.es> wrote:
> Let's be the C procedures in a module that share global data
>
>  a
>  b
>  c
>
> and I make a C library with them. This library will be used by a
> multitasked Ada95 application by the pragma Import
>
> Tasks T, Q and R may invoke a, b or c in a concurrent, uncontrolled way.
> Isn't it? I'm interested in a, b and c to be executed in mutual
> exclusion to preserve global data integrity. The question is: How do I
> do it in Ada95?
> I've thought in a protected object, such as:
>
> protected Monitor is
>   procedure a;
>   procedure b;
>   procedure c;
> end Monitor;

> Does this way guarantee mutual exclusion of a, b and c??? Any ideas??

Yup, as long as everyone goes through the Monitor protected object to call a,
b, and c. You could make this more transparent to users by just putting
procedure calls in the spec of a "C" package. Put Monitor in the body, and
have the body of the procedures call the protected procedures in Monitor.
That way it looks just like normal procedure calls to everyone else.

Of course if you are going to do it that way, it would be just as easy to
create a simple lock using a protected object, and have the bodies of all the
procedures acquire the lock, then call the imported procedure, then release
the lock.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Imported Monolitic Monitor

[Nick Roberts]

Two further small matters.  Firstly, "yup" means "yes".  Secondly, if any of
the C functions (a, b, or c) only reads the global data (but does not change
it), make it be called by a 'function' in Ada (inside the protected object),
rather than a 'procedure'.  This may execute slightly more efficiently
(because it will allow multiple tasks to read the data at the same time).

For example:

   protected Lending_Library is

      procedure Take_Out_Book (...); -- changes the library

      procedure Return_Book (...); -- changes the library

      function Has_Book (...) return Boolean; -- only reads

   end Lending_Library;

Best of luck.

-------------------------------------
Nick Roberts
-------------------------------------

Re: Imported Monolitic Monitor

[robert_dewar]

In article <7bv4jv$7om$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Two further small matters.  Firstly, "yup" means "yes".
> Secondly, if any of the C functions (a, b, or c) only
> reads the global data (but does not change it), make it
> be called by a 'function' in Ada (inside the protected
> object), rather than a 'procedure'.  This may execute
> slightly more efficiently (because it will allow multiple
> tasks to read the data at the same time).

The "will" here is wrong, the right verb is "may". In fact
we have found that most operating systems lack the
primitives to allow simultaneous reading, so usually in
GNAT, functions do not permit this kind of access, and
they use a mutual exclusion lock identical to the lock
used for procedures (as of course permitted by the RM).
Yes, you could rig up a higher level layer allowing this
synchronization, but given the usual expectation of
protected subprograms being short, this would probably
increase overhead rather than decrease it.

In any case, I suggest programmers choose between
procedures and functions in this situation on the basis
of which is the better abstraction. Worrying about low
level implementation details is not the way to create
pleasant interfaces!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own