Feature suggestion: different task schedules

Feature suggestion: different task schedules

[Victor Porton]

I propose for Ada 2020 to add the following pragmas (and corresponding 
aspects) for tasks and task types:

pragma Schedule=>Thread;

the regular task.

pragma Schedule=>Manual;

the task runs only when a protected entry is called and stops at the next 
accept statement.

This is usually the fastest mode in the case of one-core system.

pragma Schedule=>Sometimes;

the task run in either of two above modes (with tasks of a task type not 
necessarily scheduled in the same way (some may be Thread and some Manual)).

The schedule mode may be chosen dependently on free CPU cores availability 
to make it the fastest.

pragma Schedule=>Dynamic;

a task with this schedule may switch between Thread and Manual mode at any 
moment of time. This is useful to use CPU cores effectively.

What do you think?

-- 
Victor Porton - http://portonvictor.org

Re: Feature suggestion: different task schedules

[Victor Porton]

Victor Porton wrote:

> I propose for Ada 2020 to add the following pragmas (and corresponding
> aspects) for tasks and task types:
> 
> pragma Schedule=>Thread;
> 
> the regular task.
> 
> pragma Schedule=>Manual;
> 
> the task runs only when a protected entry is called and stops at the next
> accept statement.
> 
> This is usually the fastest mode in the case of one-core system.
> 
> pragma Schedule=>Sometimes;
> 
> the task run in either of two above modes (with tasks of a task type not
> necessarily scheduled in the same way (some may be Thread and some
> Manual)).
> 
> The schedule mode may be chosen dependently on free CPU cores availability
> to make it the fastest.
> 
> pragma Schedule=>Dynamic;
> 
> a task with this schedule may switch between Thread and Manual mode at any
> moment of time. This is useful to use CPU cores effectively.
> 
> What do you think?

Hm, can a Manual task interact with any task (just like normal Thread task) 
or only with its creator task? We need to settle this question first.

-- 
Victor Porton - http://portonvictor.org

Re: Feature suggestion: different task schedules

[Victor Porton]

Victor Porton wrote:

> Victor Porton wrote:
> 
>> I propose for Ada 2020 to add the following pragmas (and corresponding
>> aspects) for tasks and task types:
>> 
>> pragma Schedule=>Thread;
>> 
>> the regular task.
>> 
>> pragma Schedule=>Manual;
>> 
>> the task runs only when a protected entry is called and stops at the next
>> accept statement.
>> 
>> This is usually the fastest mode in the case of one-core system.
>> 
>> pragma Schedule=>Sometimes;
>> 
>> the task run in either of two above modes (with tasks of a task type not
>> necessarily scheduled in the same way (some may be Thread and some
>> Manual)).
>> 
>> The schedule mode may be chosen dependently on free CPU cores
>> availability to make it the fastest.
>> 
>> pragma Schedule=>Dynamic;
>> 
>> a task with this schedule may switch between Thread and Manual mode at
>> any moment of time. This is useful to use CPU cores effectively.
>> 
>> What do you think?
> 
> Hm, can a Manual task interact with any task (just like normal Thread
> task) or only with its creator task? We need to settle this question
> first.

Another solution may be to include the "parent" task in the pragma:

pragma Schedule=>Manual, Parent_Task=>...;

When calling from the parent task, we do not need to synchronize, what is 
important for compiler optimization.

Please, more ideas.

-- 
Victor Porton - http://portonvictor.org

Re: Feature suggestion: different task schedules

[Pascal Obry]

Victor,

> pragma Schedule=>Manual;
> 
> the task runs only when a protected entry is called and stops at the
> next accept statement.
> 
> This is usually the fastest mode in the case of one-core system.

I don't see the point. Call from the task the PO with a barrier. The
task will be sleeping until waken-up by an event on this PO. Isn't this
is exactly what you looking for?

Don't assume you have to do optimization yourself. Most of the time the
compiler and runtime does this for you and using the most efficient
syscall on the target.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 14/07/2017 07:59, Pascal Obry wrote:

>> pragma Schedule=>Manual;
>>
>> the task runs only when a protected entry is called and stops at the
>> next accept statement.
>>
>> This is usually the fastest mode in the case of one-core system.
> 
> I don't see the point. Call from the task the PO with a barrier. The
> task will be sleeping until waken-up by an event on this PO. Isn't this
> is exactly what you looking for?

The point, I presume, is to have co-routines. For that purpose the 
object used to yield processor is not even protected. All parties are 
synchronized already.

As a use-case consider a producer-consumer pair. Both would be 
pseudo-tasks backed by single thread of control (proper task).

> Don't assume you have to do optimization yourself. Most of the time the
> compiler and runtime does this for you and using the most efficient
> syscall on the target.

This is not the case for co-routines where transition of control is 
virtual, only there to use a task abstraction for decomposition of an 
algorithm that itself is strictly non-concurrent.

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

Re: Feature suggestion: different task schedules

[Victor Porton]

Surprisingly low response to my idea.

Should we have it in future Ada? (My opinion is "yes".)

Victor Porton wrote:
> I propose for Ada 2020 to add the following pragmas (and corresponding
> aspects) for tasks and task types:
> 
> pragma Schedule=>Thread;
> 
> the regular task.
> 
> pragma Schedule=>Manual;
> 
> the task runs only when a protected entry is called and stops at the next
> accept statement.
> 
> This is usually the fastest mode in the case of one-core system.
> 
> pragma Schedule=>Sometimes;
> 
> the task run in either of two above modes (with tasks of a task type not
> necessarily scheduled in the same way (some may be Thread and some
> Manual)).
> 
> The schedule mode may be chosen dependently on free CPU cores availability
> to make it the fastest.
> 
> pragma Schedule=>Dynamic;
> 
> a task with this schedule may switch between Thread and Manual mode at any
> moment of time. This is useful to use CPU cores effectively.
> 
> What do you think?
> 
-- 
Victor Porton - http://portonvictor.org

Re: Feature suggestion: different task schedules

[Niklas Holsti]

On 17-07-15 14:30 , Victor Porton wrote:
> Surprisingly low response to my idea.

Possibly because your presentation of the idea is hard to understand. I 
certainly do not understand what you are proposing.

Please show some example code using the proposed mechanism, explain how 
it works, and why it is better than the current mechanisms.

> Should we have it in future Ada? (My opinion is "yes".)
>
> Victor Porton wrote:
>> I propose for Ada 2020 to add the following pragmas (and corresponding
>> aspects) for tasks and task types:
>>
>> pragma Schedule=>Thread;
>>
>> the regular task.
>>
>> pragma Schedule=>Manual;
>>
>> the task runs only when a protected entry is called and stops at the next
>> accept statement.
>>
>> This is usually the fastest mode in the case of one-core system.
>>
>> pragma Schedule=>Sometimes;
>>
>> the task run in either of two above modes (with tasks of a task type not
>> necessarily scheduled in the same way (some may be Thread and some
>> Manual)).
>>
>> The schedule mode may be chosen dependently on free CPU cores availability
>> to make it the fastest.
>>
>> pragma Schedule=>Dynamic;
>>
>> a task with this schedule may switch between Thread and Manual mode at any
>> moment of time. This is useful to use CPU cores effectively.
>>
>> What do you think?
>>


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Feature suggestion: different task schedules

[Simon Wright]

Victor Porton <porton@narod.ru> writes:

> Surprisingly low response to my idea.

Perhaps people don't know what your idea actually is, and what sort of
problem it solves that can't be met with the current design of Annex D.

(I won't pretend that I understand other than the simplest features of
Annex D; they solve problems that I, in the main, don't have, and in any
case GNAT tends not to implement them on Darwin)

Re: Feature suggestion: different task schedules

[Jeffrey R. Carter]

On 07/15/2017 01:30 PM, Victor Porton wrote:
> Surprisingly low response to my idea.

1. Ada has moved away from pragmas to aspects, so why do you present pragmas?
2. If there's a reason these are pragmas, you should know how to write a pragma.
3. What problem is this supposed to solve?
4. What is there about the problem that can't be solved with the features in ARM 
D.2?

I, for one, have no idea what you're proposing, how it's supposed to work, or 
what it's supposed to do.

-- 
Jeff Carter
"Since I strongly believe that overpopulation is by
far the greatest problem in the world, this [Soylent
Green] would be my only message movie."
Charleton Heston
123

---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 2017-07-16 20:48, Jeffrey R. Carter wrote:

> 3. What problem is this supposed to solve?
> 4. What is there about the problem that can't be solved with the 
> features in ARM D.2?

3 and 4 => Any problem can be solved by means of Annex D.

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

Re: Feature suggestion: different task schedules

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2017-07-16 20:48, Jeffrey R. Carter wrote:
>
>> 3. What problem is this supposed to solve?
>> 4. What is there about the problem that can't be solved with the
>> features in ARM D.2?
>
> 3 and 4 => Any problem can be solved by means of Annex D.

Or enough levels of indirection. Or a mixture.

Re: Feature suggestion: different task schedules

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:okgc70$ipv$1@dont-email.me...
> On 07/15/2017 01:30 PM, Victor Porton wrote:
>> Surprisingly low response to my idea.
...
> 4. What is there about the problem that can't be solved with the features 
> in ARM D.2?

To be more specific, Ada 95 and later allows control of task scheduling with 
pragma , pragma, and others.

> I, for one, have no idea what you're proposing, how it's supposed to work, 
> or what it's supposed to do.

I agree. And more importantly, what it is supposed to do that can't be done 
with the pragmas noted above. And most important of all -- what problem 
needs to be solved. The ARG has no problem coming up with dozens of 
solutions to problems -- it doesn't need help with that. What it needs help 
with are the problems that you and other Ada users are running into in 
practice.

                                       Randy.

Re: Feature suggestion: different task schedules

[Randy Brukardt]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:...
...
> To be more specific, Ada 95 and later allows control of task scheduling 
> with pragma , pragma, and others.

Probably should have finished this sentence before hitting "send"!!

"To be more specific, Ada 95 and later allows control of task scheduling 
with
pragma Task_Dispatching_Policy, pragma Locking_Policy, pragma
Queuing_Policy, and others."

                           Randy.

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 18/07/2017 02:09, Randy Brukardt wrote:

> I agree. And more importantly, what it is supposed to do that can't be done
> with the pragmas noted above.

Co-routines, I suppose.

> And most important of all -- what problem
> needs to be solved.

A co-routine with task interface lacking task overhead.

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

Re: Feature suggestion: different task schedules

[Shark8]

On Tuesday, July 18, 2017 at 1:14:24 AM UTC-6, Dmitry A. Kazakov wrote:
> On 18/07/2017 02:09, Randy Brukardt wrote:
> 
> > I agree. And more importantly, what it is supposed to do that can't be done
> > with the pragmas noted above.
> 
> Co-routines, I suppose.
> 
> > And most important of all -- what problem
> > needs to be solved.
> 
> A co-routine with task interface lacking task overhead.

Is that really a problem though?

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 2017-07-18 17:28, Shark8 wrote:
> On Tuesday, July 18, 2017 at 1:14:24 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 18/07/2017 02:09, Randy Brukardt wrote:
>>
>>> I agree. And more importantly, what it is supposed to do that can't be done
>>> with the pragmas noted above.
>>
>> Co-routines, I suppose.
>>
>>> And most important of all -- what problem
>>> needs to be solved.
>>
>> A co-routine with task interface lacking task overhead.
> 
> Is that really a problem though?

Control flow inversion problem: replacing data-driven state machine mess 
with natural, readable, maintainable, safe: fetch (blocking), process, 
repeat.

P.S. For real-life applications see data-driven implementations of 
protocols in Simple Components.

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

Re: Feature suggestion: different task schedules

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:okkcgc$1m31$1@gioia.aioe.org...
> On 18/07/2017 02:09, Randy Brukardt wrote:
...
>> And most important of all -- what problem
>> needs to be solved.
>
> A co-routine with task interface lacking task overhead.

I hate to sound like a broken record, but that's a solution, not a problem. 
One would need to explain what problem(s) can't be reasonably solved with 
the existing features of Ada that could be solved with a co-routine. (And a 
purely performance argument is by far the weakest IMHO; very few programs 
are really performance bound, and most of those would value more tasking.)

                           Randy.

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 18/07/2017 22:09, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:okkcgc$1m31$1@gioia.aioe.org...
>> On 18/07/2017 02:09, Randy Brukardt wrote:
> ...
>>> And most important of all -- what problem
>>> needs to be solved.
>>
>> A co-routine with task interface lacking task overhead.
> 
> I hate to sound like a broken record, but that's a solution, not a problem.
> One would need to explain what problem(s) can't be reasonably solved with
> the existing features of Ada that could be solved with a co-routine. (And a
> purely performance argument is by far the weakest IMHO; very few programs
> are really performance bound, and most of those would value more tasking.)

It is not performance argument. It is it the first line design argument 
(control flow inversion) as I explained in another post.

I admit that I don't understand the OP proposal. It is not sufficiently 
described and scheduling is not single issue here. Not in the cases I 
have in mind.

A task based solution is non-starter for two reasons.

One is that it is not composable. I expect a co-routine proposal to 
offer a possibility to implement stacked layered protocols. I don't see 
how that would be possible on task basis. A protocol implementation may 
not be a task object.

Another reason is design and OS constraints. Protocols must be handled 
by worker tasks. Number of tasks <<< number of connections, e.g. number 
of sockets.

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

Re: Feature suggestion: different task schedules

[Victor Porton]

Dmitry A. Kazakov wrote:

> On 18/07/2017 22:09, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:okkcgc$1m31$1@gioia.aioe.org...
>>> On 18/07/2017 02:09, Randy Brukardt wrote:
>> ...
>>>> And most important of all -- what problem
>>>> needs to be solved.
>>>
>>> A co-routine with task interface lacking task overhead.
>> 
>> I hate to sound like a broken record, but that's a solution, not a
>> problem. One would need to explain what problem(s) can't be reasonably
>> solved with the existing features of Ada that could be solved with a
>> co-routine. (And a purely performance argument is by far the weakest
>> IMHO; very few programs are really performance bound, and most of those
>> would value more tasking.)
> 
> It is not performance argument. It is it the first line design argument
> (control flow inversion) as I explained in another post.
> 
> I admit that I don't understand the OP proposal. It is not sufficiently
> described and scheduling is not single issue here. Not in the cases I
> have in mind.
> 
> A task based solution is non-starter for two reasons.
> 
> One is that it is not composable. I expect a co-routine proposal to
> offer a possibility to implement stacked layered protocols. I don't see
> how that would be possible on task basis. A protocol implementation may
> not be a task object.

I don't understand why it is not composable. A task may call another tasks. 
Tasks may even call each others in a cycle.

However I think, we may have some sort of problem about specifying something 
in hypothetical Ada2020 what is similar to `yield from` in Python. It seems 
that for this we need to introduce something like "multi" accept statement, 
but I did not yet thought about this.

> Another reason is design and OS constraints. Protocols must be handled
> by worker tasks. Number of tasks <<< number of connections, e.g. number
> of sockets.

-- 
Victor Porton - http://portonvictor.org

Re: Feature suggestion: different task schedules

[Egil H H]

On Sunday, July 23, 2017 at 2:31:29 PM UTC+2, Victor Porton wrote:
> It seems that for this we need to introduce something like "multi" accept 
> statement, 

Do you mean like the selective accept (RM 9.7.1)?

select
   accept Entry_1 do
      -- something
   end Entry_1;
or 
   accept Entry_2 do
      -- something else
   end Entry_2;
end select;

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 2017-07-23 14:31, Victor Porton wrote:
> Dmitry A. Kazakov wrote:
> 
>> One is that it is not composable. I expect a co-routine proposal to
>> offer a possibility to implement stacked layered protocols. I don't see
>> how that would be possible on task basis. A protocol implementation may
>> not be a task object.
> 
> I don't understand why it is not composable. A task may call another tasks.
> Tasks may even call each others in a cycle.

I need to see an example of a layered protocol implemented this way.

> However I think, we may have some sort of problem about specifying something
> in hypothetical Ada2020 what is similar to `yield from` in Python.

I don't see why yield is even needed. In my view it must be a call with 
parameters which would in effect transfer control.

> It seems
> that for this we need to introduce something like "multi" accept statement,
> but I did not yet thought about this.

There is a problem with accept that it contains inversion in itself. 
More natural for a producer-consumer pair is when both make calls, maybe 
to a pseudo protected object, in order to pass control and data. Again I 
must see an example.

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

Re: Feature suggestion: different task schedules

[Victor Porton]

Egil H H wrote:

> On Sunday, July 23, 2017 at 2:31:29 PM UTC+2, Victor Porton wrote:
>> It seems that for this we need to introduce something like "multi" accept
>> statement,
> 
> Do you mean like the selective accept (RM 9.7.1)?
> 
> select
>    accept Entry_1 do
>       -- something
>    end Entry_1;
> or
>    accept Entry_2 do
>       -- something else
>    end Entry_2;
> end select;

No, I mean a different thing.

I am going to write about this in details later.

-- 
Victor Porton - http://portonvictor.org

Re: Feature suggestion: different task schedules

[Dennis Lee Bieber]

On Sun, 23 Jul 2017 07:19:37 -0700 (PDT), Egil H H <ehh.public@gmail.com>
declaimed the following:

>On Sunday, July 23, 2017 at 2:31:29 PM UTC+2, Victor Porton wrote:
>> It seems that for this we need to introduce something like "multi" accept 
>> statement, 
>
>Do you mean like the selective accept (RM 9.7.1)?
>

	Given my impression was totally the opposite, any proposal from the OP
will need to be completely and clearly defined in behavior in order to
reach a consensus. I was thinking this was something to do with (using
Python's yield as the example) multiple breakpoints (accepts) responding in
sequence but with only a single external name.


	IOW: Python executes code up through the next yield when invoked, and
the object is blocked after the yield returns a value. Ada accept OTOH
blocks waiting for the invocation and continues executing code after the
resultant rendezvous (only be putting all the code within the accept blocks
can you get something similar).

def theName():
	while True:
		x = do_something()
		yield x
			#block after yield
		x = do_something_else()
		yield x
			#block after yield

vs (apologies for the pseudo-Ada syntax)

loop
	#block before accept
	accept theName(out x : sometype) do
		x = do_something;
	end theName;
	#block before accept
	accept theName(out x : sometype) do	
		x = do_something_else;
	end theName;
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Feature suggestion: different task schedules

[Alejandro R. Mosteo]

On 23/07/17 14:31, Victor Porton wrote:
> Dmitry A. Kazakov wrote:
> 
>> On 18/07/2017 22:09, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:okkcgc$1m31$1@gioia.aioe.org...
>>>> On 18/07/2017 02:09, Randy Brukardt wrote:
>>> ...
>>>>> And most important of all -- what problem
>>>>> needs to be solved.
>>>>
>>>> A co-routine with task interface lacking task overhead.
>>>
>>> I hate to sound like a broken record, but that's a solution, not a
>>> problem. One would need to explain what problem(s) can't be reasonably
>>> solved with the existing features of Ada that could be solved with a
>>> co-routine. (And a purely performance argument is by far the weakest
>>> IMHO; very few programs are really performance bound, and most of those
>>> would value more tasking.)
>>
>> It is not performance argument. It is it the first line design argument
>> (control flow inversion) as I explained in another post.
>>
>> I admit that I don't understand the OP proposal. It is not sufficiently
>> described and scheduling is not single issue here. Not in the cases I
>> have in mind.
>>
>> A task based solution is non-starter for two reasons.
>>
>> One is that it is not composable. I expect a co-routine proposal to
>> offer a possibility to implement stacked layered protocols. I don't see
>> how that would be possible on task basis. A protocol implementation may
>> not be a task object.
> 
> I don't understand why it is not composable. A task may call another tasks.
> Tasks may even call each others in a cycle.
> 
> However I think, we may have some sort of problem about specifying something
> in hypothetical Ada2020 what is similar to `yield from` in Python. It seems
> that for this we need to introduce something like "multi" accept statement,
> but I did not yet thought about this.

I'm not sure if this has been discussed here or if it is even the same 
feature as in Python, but there is an AI proposal for generator 
functions using "yield":

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0197-1.txt?rev=1.7&raw=N

Álex.

> 
>> Another reason is design and OS constraints. Protocols must be handled
>> by worker tasks. Number of tasks <<< number of connections, e.g. number
>> of sockets.
> 

Re: Feature suggestion: different task schedules

[Dmitry A. Kazakov]

On 2017-07-24 17:26, Alejandro R. Mosteo wrote:
> I'm not sure if this has been discussed here or if it is even the same 
> feature as in Python, but there is an AI proposal for generator 
> functions using "yield":
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0197-1.txt?rev=1.7&raw=N 

Yield is pointless and useless as I already mentioned.

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