From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ichbiah 2022 compiler mode Date: Thu, 12 Sep 2024 10:42:38 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Qk6GnCNU1Qv5ozyhXX/njw5YGcYPAfiBif2SdbzJn+EtvidUzD Cancel-Lock: sha1:epuEBUq9rORHwN0F9kpOtnnE8LU= sha256:KMZR4lD+izvMfuE05VZ3jx5qFlpRS6IKOU+wgaqFRx0= User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:66338 List-Id: On 2024-09-12 7:46, Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:lk3fsvF7aaaU1@mid.individual.net... > ... >> I disagree with Randy's view that tasks and "parallel" are much >> overlapping. Tasks are able to communicate with each other, but AIUI >> parallel tasklets are not meant to do that, and may not be able to do >> that. Tasks can have different priorities; tasklets cannot. > > I was (of course) presuming that "tasklets" would get those capabilities if > they were to replace tasks. That's what I meant about "suspension", which is > not currently allowed for threads in Ada (parallel code is not allowed to > call potentially blocking operations). If that was changed, then all forms > of existing task communication would be allowed. Ok, I understand. In that case, what "parallel" adds to the current tasking feature is an easy way to create a largish and perhaps dynamically defined number of concurrent threads from a "parallel" loop, where the threads are automatically created when the loop is started and automatically "joined" and destroyed when the loop completes. I don't mind at all if a future Ada evolution merges tasks and "parallel", although it might defeat the easier access to multi-core true parallelism that is the goal of the "parallel" extension, AIUI. > I'm less certain about the value of priorities, most of the time, they don't > help writing correct Ada code. (You still need all of the protections > against race conditions and the like.) I do realize that they are a natural > way to express constraints on a program. So I admit I don't know in this > area, in particular if there are things that priorities are truly required > for. Priorities (or the equivalent, such as deadlines) are absolutely required for real-time systems where there are fewer cores than concurrent/parallel activities so that the system has to schedule more than one such activity on one core. If Ada did not have tasks with priorities, most of the Ada applications I have worked on in my life would have had to avoid Ada tasking and retreat to using some other real-time kernel, with ad-hoc mapping of the kernels's threads to Ada procedures. Despite the transition to multi-core processors, I think that there will continue to be systems where scheduling is required, because the number of concurrent/parallel activities will increase too.