Re: Interresting difference in Normal-Returns/Expression-Functions and Extended-Returns.

[Shark8 <onewingedshark@gmail.com>]

On Monday, April 22, 2013 1:13:47 PM UTC-6, Dmitry A. Kazakov wrote:
> On Mon, 22 Apr 2013 11:27:09 -0700 (PDT), Shark8 wrote:
> 
> > I recently ran into unexpected behavior in the differences between a
> > normal return and an extended return [in GNAT]: namely an extended return
> > used to generate items in an array of tasks will *ALWAYS* execute in a
> > sequential manner whereas the array generated with an expression-function
> > or normal return is executed simultaneously.
> > 
> > Is there some subtle difference in the extended return that I'm unaware of? (Is this a bug?)
> 
> 
> No difference (tested under Windows).

Here's some output:

C:\Programming\Projects\temp\Experiment.exe
TEST_1:	Expression Function
Dave	 0.133781955
Bob	 0.304577380
Joey	 0.536659479
Steve	 0.699105740

TEST_2:	Normal Return Function
Joey	 0.226854607
Dave	 0.444059044
Steve	 0.499072224
Bob	 0.636090755

TEST_3:	Extended Return Function
Bob	 0.566724062
Steve	 0.118256144
Dave	 0.442499906
Joey	 0.711671948

Terminating.
[2013-04-22 14:00:45] process terminated successfully (elapsed time: 03.35s)

Notice that the second column (delay-time) of the first two test-cases is *ALWAYS* sorted in ascending order, this is as expected; the difference is the last test-case which is *NOT* in ascending order.

> Issues with the code:
> 
> 1. Add 2 s delay in each test in order to see all tasks completed.

... that's not an issue; they're all completing.

> Delay
> also causes context switching. When you use null statement the main task
> likely to manage to create all contestant before any of them gains the
> processor (depending on OS settings and number of cores available). 

I have four cores; that shouldn't be a problem though -- I'm using the protected object to manage my text-output debugging.

> 2. The code leaks memory. I am sure you know that.

It's rather irrelevant insofar as I know; this is only to illustrate that task-accesses are behaving differently with normal returns than they are for extended returns.

> 3. Do not return anonymous access objects created by allocator new. It is
> almost always a bug.

Yeah, adding a named access-type probably would clean up the code a little.

> 4. Keywords to be written all lower case, if you want others be able to
> read your code.

... and here I thought we had these nifty tools for formatting source-code according to the user's preference. It is not my fault these aren't well-integrated into your IDE/text-editor. -- IOW, if casing mattered I'd expect it to be enforced by the language.