comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Proposal: Auto-allocation of Indefinite Objects
Date: Sun, 23 Aug 2020 14:28:46 +0200	[thread overview]
Message-ID: <rhtndt$u89$2@gioia.aioe.org> (raw)
In-Reply-To: rhsta6$b2r$1@franka.jacob-sparre.dk

On 23/08/2020 07:03, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rhnrtu$rk2$1@gioia.aioe.org...
>> On 21/08/2020 01:25, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:rhmd3c$1eql$1@gioia.aioe.org...
>>>> On 20/08/2020 02:13, Randy Brukardt wrote:
>>> ...
>>>>>> What you do if such an object is allocated via pool-specific access
>>>>>> type?
>>>>>
>>>>> The whole object goes in that pool. The entire mechanism in Janus/Ada
>>>>> is
>>>>> built around pools - the stack is represented by a pool object as well
>>>>> as
>>>>> various other pools to support the mechanism.
>>>>
>>>> OK, but then you are back to the problem that you do not know how that
>>>> pool works. The user pool might require a certain order of objects
>>>> inside
>>>> it and your interference with relocation will break it.
>>>
>>> Such a pool does not implement the interface as defined in 13.11. It's OK
>>> of
>>> course to write a pool that depends on implementation-specific properties
>>> (I've done it many times), but such a pool is not usable with portable
>>> Ada
>>> code. If the pool allows any sort of allocation at any time, then it will
>>> work just fine with the Janus/Ada implementation.
>>
>> It is a different situation. Such pools are not intended as a general
>> purpose pools. But the type is. In my view an implementation of the type
>> provided by compiler must work in all legal cases. Otherwise it is either
>> language of compiler bug.
> 
> There's a third possibility: unrealistic expectations. :-)
> 
> The only kind of pool that is not general-purpose is one that is necessarily
> depending on the details of the implementation. Trying to constrain what
> allocations a compiler can do would ensure that a language could not be
> implemented efficiently or flexibly. That's not a language I'd want to use.
> 
> ...
>> It could be very expensive on a multi-core architecture.
> 
> I suppose, but that architecture would be lousy for running any
> multi-tasking or parallel program (since any such program is going to need a
> significant amount of synchronization). A lock-free algorithm is usually the
> cheapest possible synchronization on any architecture (it usually includes a
> spin, but the spin is almost never executed).
> 
>   > .. I also think
>> about scenarios when the object is used inside a protected action. I would
>> not like to see any pool interaction in an interrupt handler!
> 
> Interrupt handlers shouldn't be doing anything other than unblocking tasks.
> I think it is a mistake to allow anything else (as there are always problems
> with race conditions if you do so). So no heap possibilities as very little
> is going on.

Yes, and this is why light-weight implementations are important. You 
want to take them away while giving no promises, no, actually promising 
that expecting the alternative to work would be: "an unrealistic 
expectation." (:-))

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

  reply	other threads:[~2020-08-23 12:28 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 22:48 Proposal: Auto-allocation of Indefinite Objects Stephen Davies
2020-04-03 23:45 ` Stephen Leake
2020-04-04 10:54   ` Jeffrey R. Carter
2020-04-04 20:55     ` Stephen Davies
2020-04-04  8:31 ` Dmitry A. Kazakov
2020-07-27  7:47 ` Yannick Moy
2020-07-27  9:21   ` J-P. Rosen
2020-07-27  9:49     ` Dmitry A. Kazakov
2020-07-27 17:48   ` Brian Drummond
2020-07-27 20:02     ` Dmitry A. Kazakov
2020-07-28 14:28       ` Brian Drummond
2020-07-28 14:59         ` Dmitry A. Kazakov
2020-07-29 15:33           ` Brian Drummond
2020-07-29 16:20             ` Dmitry A. Kazakov
2020-07-30 13:37               ` Stephen Davies
2020-07-30 14:23                 ` Dmitry A. Kazakov
2020-07-30 17:04               ` Brian Drummond
2020-07-30 18:28                 ` Dmitry A. Kazakov
2020-08-10  0:39                   ` Randy Brukardt
2020-08-10  8:57                     ` Dmitry A. Kazakov
2020-08-20  0:10                       ` Randy Brukardt
2020-08-20 17:49                         ` Dmitry A. Kazakov
2020-08-20 20:19                           ` Dennis Lee Bieber
2020-08-20 23:33                             ` Randy Brukardt
2020-08-21  6:45                               ` Dmitry A. Kazakov
2020-08-23  4:52                                 ` Randy Brukardt
2020-08-23 12:28                                   ` Dmitry A. Kazakov
2020-08-20 23:30                           ` Randy Brukardt
2020-08-21  6:46                             ` Dmitry A. Kazakov
2020-08-23  4:48                               ` Randy Brukardt
2020-08-23 12:29                                 ` Dmitry A. Kazakov
2020-08-10  0:31               ` Randy Brukardt
2020-08-10  8:58                 ` Dmitry A. Kazakov
2020-08-20  0:13                   ` Randy Brukardt
2020-08-20 17:49                     ` Dmitry A. Kazakov
2020-08-20 23:25                       ` Randy Brukardt
2020-08-21  7:08                         ` Dmitry A. Kazakov
2020-08-23  5:03                           ` Randy Brukardt
2020-08-23 12:28                             ` Dmitry A. Kazakov [this message]
2020-07-27 20:31     ` Jeffrey R. Carter
2020-07-31  9:25 ` Stephen Davies
2020-07-31 10:20   ` Dmitry A. Kazakov
2020-08-01 11:22     ` Stephen Davies
2020-08-01 12:58       ` Dmitry A. Kazakov
2020-08-01 20:35         ` Stephen Davies
2020-08-01 20:56           ` Dmitry A. Kazakov
2020-09-03  4:30 ` linda white
replies disabled

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