multi reads, single write

multi reads, single write

[Vladimir Olensky]

Few days  ago I mentioned about  comp.programming.threads
group where I found no referencies to Ada at all.  I thought that
it is not very good and I replied there at some posts.
One of them to "multi reads, single write" post caused
some discussion about Ada.

Anyone who is interested in promoting Ada there
could join that discussion.

Multitasking is one of the outstanding Ada features and
I am sure that Ada should be presented at
comp.programming.threads.

Regards,
Vladimir

Re: multi reads, single write

[Samuel T. Harris]

Vladimir Olensky wrote:
> 
> Few days  ago I mentioned about  comp.programming.threads
> group where I found no referencies to Ada at all.  I thought that
> it is not very good and I replied there at some posts.
> One of them to "multi reads, single write" post caused
> some discussion about Ada.
> 
> Anyone who is interested in promoting Ada there
> could join that discussion.
> 
> Multitasking is one of the outstanding Ada features and
> I am sure that Ada should be presented at
> comp.programming.threads.
> 
> Regards,
> Vladimir

Why don't you include comp.lang.ada in your posts
to comp.programming.threads? That way this audience
will naturally contribute to that audience and
vice versa.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"

Re: multi reads, single write

[Vladimir Olensky]

Tom Payne wrote in message <833uh9$e4p$1@pravda.ucr.edu>...
>Vladimir Olensky <vladimir_olensky@yahoo.com> wrote:
>[...]
>> First of all Kostas Kostiadis (original poster) was asking: "Hello
>> all, I just want to ask your opinion(s) as to what is the most
>> efficient way to implement a "multiple-reads, single write"
>> scenario."
>[...]
>> My answer was exactly how to do that in a very simple and efficient
>> way - using protected types in Ada that are specially designed for
>> "multi-read single write" scenario in multithreaded/multitasking
>> environment.
>
>Your answer does not, however, respond to the question of "what is the
>most efficient way to implement" a CREW protocol.  It merely states
>that all Ada implementations have a built-in implementation, which is
>interesting but not particularly helpful.


Ada 95  implementations guarantee  that  this is done in the most
efficient way for a given platform.
Remember that Ada 95 was designed for "hard" real-time systems
including embedded ones.

Regards,
Vladimir Olensky


=============================================
Some quotes from Ada ARM (9.1):


From the implementation perspective, a protected object
is designed to be a very efficient conditional critical
region (see 9.1.3). The protected operations are automatically
synchronized to allow only one writer or multiple readers.
The protected operations are defined using a syntax similar
to a normal subprogram body, with the mutual exclusion of
the critical region happening automatically on entry, and
being released automatically on exit.


9.1.3 Efficiency of Protected Types
Protected types provide an extremely efficient mechanism;
the ability to use the thread of control of one task to execute
a protected operation on behalf of another task reduces the
overhead of context switching compared with other paradigms.
Protected types are thus not only much more efficient than the
use of an agent task and associated rendezvous, they are also
more efficient than traditional monitors or semaphores in many
circumstances.
<...>
Ada 95 protected objects are an amalgam of the best features
of conditional critical regions and monitors: they collect all the
data and operations together, like monitors, and yet they have
barriers, like conditional critical regions. The barriers describe
the required state that must exist before an operation can be
performed in a clear manner which aids program proof and
understanding. Protected objects are very similar to the shared
objects of the Orca language developed by Bal, Kaashoek and
Tanenbaum [Bal 92].

Re: multi reads, single write

[Tom Payne]

In comp.programming.threads Vladimir Olensky <vladimir_olensky@yahoo.com> wrote:

> Tom Payne wrote in message <833uh9$e4p$1@pravda.ucr.edu>...

[...]

>>Vladimir Olensky <vladimir_olensky@yahoo.com> wrote:
>>[...]
>>> My answer was exactly how to do that in a very simple and efficient
>>> way - using protected types in Ada that are specially designed for
>>> "multi-read single write" scenario in multithreaded/multitasking
>>> environment.
>>
>>Your answer does not, however, respond to the question of "what is the
>>most efficient way to implement" a CREW protocol.  It merely states
>>that all Ada implementations have a built-in implementation, which is
>>interesting but not particularly helpful.

[...]
> =============================================
> Some quotes from Ada ARM (9.1):
[...]
> Ada 95 protected objects are an amalgam of the best features
> of conditional critical regions and monitors: they collect all the
> data and operations together, like monitors, and yet they have
> barriers, like conditional critical regions. The barriers describe
> the required state that must exist before an operation can be
> performed in a clear manner which aids program proof and
> understanding. Protected objects are very similar to the shared
> objects of the Orca language developed by Bal, Kaashoek and
> Tanenbaum [Bal 92].

That's helpful and interesting, especially the last sentence.

Thanks,  ;-)

Tom Payne

Re: multi reads, single write

[Vladimir Olensky]

Kaz Kylheku wrote in message ...
>On Tue, 14 Dec 1999 01:28:12 +0300, Vladimir Olensky


><vladimir_olensky@yahoo.com> wrote:
>>With second one the answer is  that  Ada95 was designed for
>>embedded and real-time systems and protected types were
>>introduced into Ada 95 to provide most efficient implementation
>>of "multi-read single write" operation.  Any Ada implementation
>>that support Real-Time Annex (e.g. GNAT) does that in a most
>>efficient way possible for a given platform.
>
>What about implementations that don't support the Real-Time annex?


I do not know such ones.
At least these annexes are supported by the implementations
that I've seen so far:
     Annex A - Predefined Library Environment
     Annex B - Interfaces to Languages
     Annex C - Systems Programming
     Annex D - Real-Time Systems
     Language Defined Attributes (Annex J)
     Language Defined Pragmas (Annex K)


GNAT implements all special needs annexes:
    Systems Programming (Annex C)
    Real-Time Systems (Annex D)
    Distributed Systems (Annex E)
               Stub generation is fully implemented, but no PCS is provided
yet,
              so distributed systems cannot yet be constructed with this
version
              of GNAT.
    Information Systems (Annex F)
    Numerics (Annex G)
    Safety and Security (Annex H)
    Obsolescent Features (Annex I)
    Language Defined Attributes (Annex J)
    Language Defined Pragmas (Annex K)

Real-Time annex just gives many additional options to control multitasking.
It also imposes some restrictions on Clock granularity.

>Moreover, how can GNAT generate hard real time applications on systems
>that aren't real time, or are soft real time, like say most UNIXes?


If one wants to build "hard" real-time system then one will use
any appropriate "hard" Real-Time OS (RTOS) among existing or
may be even no underlying OS at all.
All that options are available.

>Whether or not a given programming system is real time or not depends
>a great deal on the guarantees provided by its environment.


See above.


>For the compiler for a given language to be suitable for real-time work, it
>just needs to generate reasonably well behaved machine code.


Yes, I agree here.
But if language do not provide built-in mechanism for  real-time
multitasking,
then one should reinvent the wheel using  low-level stuff.

>That is a function of the language implementation. It's not reasonable for
a
>language standard to impose limits on how many nanoseconds a given
operation,
>such as access to an object, must take.

Sometimes it reasonable. At least for "hard" real-time systems.

>Some languages are not well-suited time use. E.g. languages with implicit
>dynamic alloocation garbage collection,

That's why Ada does not use garbage collection by default.
Ada provide several mechanisms to provide efficient resources
deallocation.

>or with implicit run-time algorithms
>whose duration is difficult to estimate, or implicit uses of heavy weight
>resources such as databases, networks and the like.


This is separate big topic that is beyond the original thread.

Regards,
Vladimir Olensky

Re: multi reads, single write

[Mike Silva]

I've cross-posted this to comp.lang.ada because I'm interested in any
insight they may have there.  While an Ada task entry can easily do such
bounded waiting (see e.g. http://www.adahome.com/Ammo/cpp2ada.html "7.2.4
delays"), it appears from my newbie reading on protected types that they do
not allow this.  Perhaps this is due to efficiency considerations regarding
barrier evaluation (despite some comments here, the design of protected
types was strongly constrained by efficiency considerations), and/or by the
need of the protected functions and procedures to indicate a timeout
condition, but that's all just me supposing...

Anyway, I imagine it's easy to channel accesses to protected types through
task entries which do bounded waiting, but I don't know what subtleties
might arise.  I hope the Ada experts can point out the best solution to the
question.

Mike

Joe Seigh wrote in message <3858F8FA.CA9BD032@bbnplanet.com>...

>> Example  of "wait free"  using  protected type declaration:
>>
>>        protected type Resource is
>>             entry Seize;
>>             procedure Release;
>>        private
>>             Free : Boolean := True;
>>        end Resource;
>>
>>        protected body Resource is
>>              entry Seize when Free is
>>           begin
>>                Free := False;
>>           end Seize;
>>
>>           procedure Release is
>>           begin
>>               Free:= True;
>>           end Release;
>>        end Resource;
>>
>> Very simple, isn't it ?
>>
>
>I don't understand how this is "wait free".  "wait free" is bounded
waiting, no indefinite
>waits allows.  What guarantees that the barrier is set to True within some
fixed amount
>of time?
>
>Joe Seigh

Re: multi reads, single write

[Laurent Guerby]

"Mike Silva" <mjsilva@jps.net> writes:
> I've cross-posted this to comp.lang.ada because I'm interested in any
> insight they may have there.  While an Ada task entry can easily do such
> bounded waiting (see e.g. http://www.adahome.com/Ammo/cpp2ada.html "7.2.4
> delays"), it appears from my newbie reading on protected types that they do
> not allow this.  [...]

They do, a protected entry is just like a task entry. The difference
is between protected procedure and protected entries. Calling a protected
procedure is conceptually not blocking (the model is spin locking).

Example of bounded waiting on an entry:

   R : Resource;

   ...

   select
      R.Seize;
   or
      delay 1.0;
      --  resource still not available after 1 second, try something else
   end select;

--LG

Re: multi reads, single write

[Mike Silva]

Ah, thanks for the answer, and for clearing up my confusion (looking back on
what I wrote I'm scratching my head wondering what I thought I meant <g>)
Yes, of course, the timeout would occur in an entry, not a function or
procedure.  Thanks again.

Mike

Laurent Guerby wrote in message
<861z8mfthx.fsf@ppp-107-102.villette.club-internet.fr>...

>>...it appears from my newbie reading on protected types that they do
>> not allow this.  [...]
>
>They do, a protected entry is just like a task entry. The difference
>is between protected procedure and protected entries. Calling a protected
>procedure is conceptually not blocking (the model is spin locking).
>
>Example of bounded waiting on an entry:
>
>   R : Resource;
>
>   ...
>
>   select
>      R.Seize;
>   or
>      delay 1.0;
>      --  resource still not available after 1 second, try something else
>   end select;
>
>--LG