Implementation Locks

Implementation Locks

[sbelmont700]

In the past, using other languages, I spent lots of time worrying about whether I should use a spinlock or a semaphore based on how long an sequence of operations was expected to be and how many CPU's were on the system, and wrote lots of overly complicated code to chose the best option in each situation.

Now in Ada, I have difficulty giving up the habit and lay awake at night worrying about whether the implementation is going busy-wait or block for a protected action or closed entry, especially now that everyone has multicore CPU's.  I'm particularly consternated by closed entries, since I doubt the compiler can predict whether it will open back up in several microseconds or in several days.  Is it unreasonable to expect an implementation to use some sort of dynamic, hybrid model that takes into account both how many CPU's are in the system and the average time to wait?  Should I just trust the runtime and try not to worry?  Is there even anything I can do about it either way?

-sb

Re: Implementation Locks

[Jeffrey Carter]

On 02/15/2014 01:20 PM, sbelmont700@gmail.com wrote:
>
> Now in Ada, I have difficulty giving up the habit and lay awake at night
> worrying about whether the implementation is going busy-wait or block for a
> protected action or closed entry, especially now that everyone has multicore
> CPU's.  I'm particularly consternated by closed entries, since I doubt the
> compiler can predict whether it will open back up in several microseconds or
> in several days.  Is it unreasonable to expect an implementation to use some
> sort of dynamic, hybrid model that takes into account both how many CPU's are
> in the system and the average time to wait?  Should I just trust the runtime
> and try not to worry?  Is there even anything I can do about it either way?

You should trust the implementation, and measure your results. If you're meeting 
your timing requirements, then you have nothing to worry about.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Implementation Locks

[G.B.]

On 15.02.14 21:20, sbelmont700@gmail.com wrote:
> Is it unreasonable to expect an implementation to use some sort of dynamic, hybrid model that takes into account both how many CPU's are in the system and the average time to wait?  Should I just trust the runtime and try not to worry?  Is there even anything I can do about it either way?

Other than proving that the situation cannot arise? 8-)

With many cores available, you could have one surveyor task
that awakes every second or so, for looking at volatile
Booleans that are global enough to be known to the other
tasks, one for each task: the other tasks would "ping"
their respective variables no later than a known good number
of microseconds, thus setting their Booleans to true.
The surveyor task clears them, and takes corresponding action
if one of the variable is false.

A task of this sort would only need the Ada features
available under profile Ravenscar, I think.