Re: Teaching new tricks to an old dog (C++ -->Ada)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 08 Mar 2005 15:13:20 -0500, CTips wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:
>> 
>>>How easy is it to build an arena allocator in Ada?
>> 
>> It is trivial:
>> 
>> type Object is ...;
>> type Object_Ptr is access Object;
>> for Object_Ptr'Storage_Pool use My_Arena;
>> 
>> Here you are:
>> 
>> Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena
> 
> And how is My_Arena defined? Is it just a blob of memory? Or is it a 
> "class" that can invoke sbrk (or whatever) when it needs to?

It is completely up to you. My_Arena has to be derived from
System.Storage_Pools.Root_Storage_Pool. Which is the abstract base of all
storage pools. The implementation of Allocate and Deallocate is at your
discretion. For an arena the pool may contain a statically allocated array
organized as a stack. Deallocate could be then void, or it can pop
everything above it as in mark'n'release. A more advanced application could
allocate memory in segments at request etc. For a sample implementation of
a segmented stack pool see:

http://www.dmitry-kazakov.de/ada/components.htm#Pools_etc 

>>>Given a processor with load-word-locked and store-word-conditional, how 
>>>would I build an atomic increment function?
>> 
>> Why should I have atomic increment function? Ada has native concurrency
>> support. But if somebody would need that extremely low level thing as
>> atomic integers, then:
>> 
>> protected type Atomic_Integer is
>>    procedure Increment;
>> private
>>    Value : Integer;
>> end Atomic_Integer;
>> 
>> -- Implementation
>> protected body Atomic_Integer is
>>    procedure Increment is
>>    begin
>>       Value := Value + 1;
>>    end Increment;
>> end Atomic_Integer;
>> 
> Will that generate:
>    L0:
>        lwlock temp,&Value
>        add    temp,temp,1
>        stwcond temp,&Value
>        if( failed ) goto L0;
> or will it generate something much more heavy-weight.

Ask your compiler vendor. Though it wouldn't be necessarily polling. Also
usually protected objects are not used for so utterly fine-grained mutual
exclusion/locking. Atomic integer increment is normally just a small part
of some larger (but not lengthy) operation. For example, placing something
in a queue. Therefore spinning for a lock (which probably would be the
implementation) will likely be less expensive than some tricky guards
attached to each and every instruction. Note also that at such a low level
it would be very difficult if possible to maintain data consistency.
Compiler simply does not know what is related to what and will try to cope
with the worst case scenario. Protected types in Ada are to describe this
sort of semantics. So in the end atomic integers are pretty useless, no
matter how efficient they could be implemented.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de