Isn't this in favour of Ada??

Isn't this in favour of Ada??

[Erlo Haugen]

http://www.gotw.ca/publications/concurrency-ddj.htm

I think so.

-- 
Erlo
-----

The statements and opinions are mine and does not
neccesarily reflect those of my employers

Re: Isn't this in favour of Ada??

[Mike Silva]

I think so too.  Of course the article only mentions Java and C++.  Big
surprise there.

Re: Isn't this in favour of Ada??

[Jeffrey Carter]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

Mike Silva wrote:
> I think so too.  Of course the article only mentions Java and C++.  Big
> surprise there.

Everything technical about SW development favors the use of well 
designed languages such as Ada by SW engineers. Everything economic 
favors the current system where the construction workers (coders) design 
the bridges (SW) and choose the materials (languages) to build them 
with. Adding concurrency to the mix won't change that, though it will 
probably reduce quality even further.

Ada is a language for SW engineers; C and its offspring are languages 
for coders. Since we allow coders to choose languages, it's not 
surprising that they choose coders' languages.

Even when Ada is used for concurrent systems, Ada's concurrency features 
are often not used. While technical reasons are often given for such 
decisions, they rarely are true. Generally, the real reasons are the 
designers' lack of understanding of concurrency, replacing it with 
something more familiar.

Why don't we allow construction workers to design bridges and choose the 
materials? Because when they fail, we lose enormous lawsuits, and that 
more than offsets the savings obtained. Because when they fail, people 
die in ways that attract the attention of regulators. When the same is 
true of SW, perhaps we will see a distinction between SW engineers and 
coders, and Ada will become more prevalent.

In the meantime, my experience is that only about 2% of developers are 
SW engineers, so I'm glad Ada isn't popular. If Ada were popular, it 
would mean it was badly designed.

[-- Attachment #2: spam.vcf --]
[-- Type: text/x-vcard, Size: 177 bytes --]

begin:vcard
fn:Jeffrey Carter
n:;Jeffrey Carter
email;internet:jeffrey_r_carter-nr [commercial-at] raytheon [period | full stop] com
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: Isn't this in favour of Ada??

[Marc A. Criley]

Jeffrey Carter wrote:

> Even when Ada is used for concurrent systems, Ada's concurrency features 
> are often not used. While technical reasons are often given for such 
> decisions, they rarely are true. Generally, the real reasons are the 
> designers' lack of understanding of concurrency, replacing it with 
> something more familiar.

Unfortunately I've found this to be all too true :-(  I've been involved 
with fixing up more than one system (long after the original designers 
have moved on) that had horrendous misuse of tasking.

One had tasks handling the buffering of data in and out of sockets.  A 
reasonable application of tasking, yes?

Except all the interaction between the tasks and the application 
occurred _within_ the 'accept' blocks.  Meaning a message would come on 
the socket and into the socket-monitoring task, rendezvous and block on 
the buffering task, which would rendezvous and block on the message 
processing task, which would generate output that would rendezvous and 
block on the output buffering task, which would rendezvous and block on 
the output socket transmission task, which then write out the message, 
followed by unblock, unblock, unblock, etc.  I am not making this up.

I characterized this as the world's most expensive procedure call chain.

-- Marc A. Criley
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Isn't this in favour of Ada??

[Marin David Condic]

I've seen similar things. ;-)

But ultimately, you're not going to get much better understanding of how 
to use Ada unless Ada gets used more generally. People who get dumped 
onto a project done in Ada and then return back to other activities 
(because Ada is not used extensively, making it a possible career) don't 
spend enough time there to get good at it & really understand the 
language. They don't necessarily operate in an environment where there 
is long-term institutional knowledge built up around what is the best 
way to do things.

If Ada got out of its position as being a niche-language and got, say, 
20% of the software development market? - there would be a lot more 
widespread knowledge of "Best Practices" and you wouldn't see as much 
incorrect featrue usage.

But that means Ada has to show up in product development and that means 
that people who think Ada is a good thing have to apply it in developing 
new & successful products. That takes entrepeneurs. More of us have to 
do that.

MDC


Marc A. Criley wrote:

> 
> Unfortunately I've found this to be all too true :-(  I've been involved 
> with fixing up more than one system (long after the original designers 
> have moved on) that had horrendous misuse of tasking.
> 
> One had tasks handling the buffering of data in and out of sockets.  A 
> reasonable application of tasking, yes?
> 
> Except all the interaction between the tasks and the application 
> occurred _within_ the 'accept' blocks.  Meaning a message would come on 
> the socket and into the socket-monitoring task, rendezvous and block on 
> the buffering task, which would rendezvous and block on the message 
> processing task, which would generate output that would rendezvous and 
> block on the output buffering task, which would rendezvous and block on 
> the output socket transmission task, which then write out the message, 
> followed by unblock, unblock, unblock, etc.  I am not making this up.
> 
> I characterized this as the world's most expensive procedure call chain.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[James Alan Farrell]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

Marin David Condic wrote:
> I've seen similar things. ;-)
> 
> But ultimately, you're not going to get much better understanding of how 
> to use Ada unless Ada gets used more generally. People who get dumped 
> onto a project done in Ada and then return back to other activities 
> (because Ada is not used extensively, making it a possible career) don't 
> spend enough time there to get good at it & really understand the 
> language. They don't necessarily operate in an environment where there 
> is long-term institutional knowledge built up around what is the best 
> way to do things.
> 
> If Ada got out of its position as being a niche-language and got, say, 
> 20% of the software development market? - there would be a lot more 
> widespread knowledge of "Best Practices" and you wouldn't see as much 
> incorrect featrue usage.
> 
> But that means Ada has to show up in product development and that means 
> that people who think Ada is a good thing have to apply it in developing 
> new & successful products. That takes entrepeneurs. More of us have to 
> do that.
> 
> MDC
> 
> 
> Marc A. Criley wrote:
> 
>>
>> Unfortunately I've found this to be all too true :-(  I've been 
>> involved with fixing up more than one system (long after the original 
>> designers have moved on) that had horrendous misuse of tasking.
>>
>> One had tasks handling the buffering of data in and out of sockets.  A 
>> reasonable application of tasking, yes?
>>
>> Except all the interaction between the tasks and the application 
>> occurred _within_ the 'accept' blocks.  Meaning a message would come 
>> on the socket and into the socket-monitoring task, rendezvous and 
>> block on the buffering task, which would rendezvous and block on the 
>> message processing task, which would generate output that would 
>> rendezvous and block on the output buffering task, which would 
>> rendezvous and block on the output socket transmission task, which 
>> then write out the message, followed by unblock, unblock, unblock, 
>> etc.  I am not making this up.
>>
>> I characterized this as the world's most expensive procedure call chain.
>>
> 
I think the biggest reason for things like this is lack of really good 
books that do a good job of explaining Ada tasking.  We have five or six 
different books lying around the office with names like "Object Oriented 
  Programming in Ada" (which gives a good overview of the basic features 
of Ada, with a few notes on object oriented programming added as an 
after thought), "Ada as a second language", etc.  None do a good job of 
covering advanced features of Ada, such as tasking, or Ada's object 
oriented programming.

JAF

[-- Attachment #2: jfarrell.vcf --]
[-- Type: text/x-vcard, Size: 88 bytes --]

begin:vcard
fn:James Alan Farrell
n:Farrell;James
org:GrammaTech
version:2.1
end:vcard

Re: Isn't this in favour of Ada??

[Ed Falis]

On Tue, 19 Jul 2005 13:03:55 -0400, James Alan Farrell  
<jfarrell@nospam.com> wrote:

> I think the biggest reason for things like this is lack of really good  
> books that do a good job of
> explaining Ada tasking.


Burns & Welling "Concurrency in Ada".

Re: Isn't this in favour of Ada??

[Marin David Condic]

Tasking does tend to suffer in that regard. A good text that not only 
had step-by-step introduction of tasking but a bunch of practical 
examples of when to use it (and when not to) would be a good thing. 
There are web pages that would publish it if it was reasonably well done.

MDC

James Alan Farrell wrote:

> I think the biggest reason for things like this is lack of really good 
> books that do a good job of explaining Ada tasking.  We have five or six 
> different books lying around the office with names like "Object Oriented 
>  Programming in Ada" (which gives a good overview of the basic features 
> of Ada, with a few notes on object oriented programming added as an 
> after thought), "Ada as a second language", etc.  None do a good job of 
> covering advanced features of Ada, such as tasking, or Ada's object 
> oriented programming.
> 
> JAF

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[Erlo Haugen]

Jeffrey Carter wrote:
> 
> Why don't we allow construction workers to design bridges and choose the 
> materials? Because when they fail, we lose enormous lawsuits, and that 
> more than offsets the savings obtained. Because when they fail, people 
> die in ways that attract the attention of regulators. When the same is 
> true of SW, perhaps we will see a distinction between SW engineers and 
> coders, and Ada will become more prevalent.
>

Guess your are right here.

> In the meantime, my experience is that only about 2% of developers are 
> SW engineers, so I'm glad Ada isn't popular. If Ada were popular, it 
> would mean it was badly designed.

So, us morons who don't have have university degree shouldn't be allowed 
to use Ada?
Anything popular is badly designed, is that Your view?
-- 
Erlo
-----

The statements and opinions are mine and does not
neccesarily reflect those of my employers

Re: Isn't this in favour of Ada??

[Jeffrey Carter]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Erlo Haugen wrote:
> So, us morons who don't have have university degree shouldn't be allowed 
> to use Ada?

In my experience, education has little to do with it. The qualities that 
distinguish SW engineers from coders seem to be intrinsic. No amount of 
education will convince most coders to use Ada, while those who have the 
makings of SW engineers tend to adopt it once they become aware of it.

I certainly don't object to coders using Ada.

> Anything popular is badly designed, is that Your view?

 From the point of view of SW engineering that tends to be true. C may 
be perfectly designed from a coders' perspective.

[-- Attachment #2: spam.vcf --]
[-- Type: text/x-vcard, Size: 177 bytes --]

begin:vcard
fn:Jeffrey Carter
n:;Jeffrey Carter
email;internet:jeffrey_r_carter-nr [commercial-at] raytheon [period | full stop] com
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: Isn't this in favour of Ada??

[Dan McLeran]

I don't think one can say that SW engineers use Ada and everyone else
is a coder. I'm sure we all know of some skilled people who do not
promote or use Ada. Having said that, I do believe that Ada is the best
tool out there for the creation of software that does what the
engineer/coder intended, which makes me wonder why programmers as a
whole do not gravitate towards the best tools available. Is syntax that
important? I'm starting to wonder what's wrong with SW engineers. There
seems to be an almost religious attachment to programming language. I
don't perceive the same kind of behaviour out of other engineering
disciplines. You'd be hard pressed to find a structural engineer who
refuses to use a superior tool/building process/etc. just because
he/she is used to doing things a different way. This kind of thought
process seemingly doesn't enter their minds. As long as cost is not
prohibitive, these engineers will use the best tools/materials for
their job because they don't want their bridges and buildings
collapsing on us. Do SW engineers not feel the same sense of
responsibility for their products? In our (programming) community there
seems to be alot of zealotry about the tools we use to build software.
Since when does personal preference count for anything when the goal is
a quality product that behaves as expected by the customer?

Re: Isn't this in favour of Ada??

[Adrien Plisson]

Dan McLeran wrote:
> I don't think one can say that SW engineers use Ada and everyone else
> is a coder. I'm sure we all know of some skilled people who do not
> promote or use Ada. Having said that, I do believe that Ada is the best
> tool out there for the creation of software that does what the
> engineer/coder intended, which makes me wonder why programmers as a
> whole do not gravitate towards the best tools available. Is syntax that
> important? 

IMHO, it's not only a syntax problem. Ada may be the best tool 
available for some development task, but unfortunately NOT for ALL 
develoment tasks. for example, i often use Python: its interpreter 
allows me to enter an expresion and directly see the result, i can't 
do that with Ada.

every language has its own advantages and weaknesses, which does not 
make them useful for all tasks. some languages can be used in more 
contexts, while others are niche languages. the old adage "use the 
right tool for the right job" applies to software development too.

unfortunately, people confuse "the right tool" with "the ultimate 
tool" and tend to always use the same languages whatever the context, 
even if the language is clearly not apropriate for their tasks.

> I'm starting to wonder what's wrong with SW engineers. 

you should ask: what's wrong with computing in general ?

the computing field is directed by worst quality softwares running on 
poorly designed platforms inheriting from bad management decisions 
made 20 years ago. this is not the best house for breeding software 
engineers.

newcomers in the field can't tell the difference between the good and 
the bad because they have only been in contact with the bad. how many 
people i know have never touched anything else than a PC under Windows 
? they can't even imagine there could be something else !

as for life on earth, diversity is the key: diversity is disappearing, 
leaving only consanguine degenerates.

 > [...]
 > Do SW engineers not feel the same sense of
> responsibility for their products? In our (programming) community there
> seems to be alot of zealotry about the tools we use to build software.
> Since when does personal preference count for anything when the goal is
> a quality product that behaves as expected by the customer?

not every software engineer has to write safety critical softwares, so 
people tend to minimize the importance of product quality (generally 
to maximise profit). if software quality had an impact on engineers 
life (i mean, revenue), they would take it more seriously.

-- 
rien

Re: Isn't this in favour of Ada??

[Jeffrey Carter]

Dan McLeran wrote:
> I don't think one can say that SW engineers use Ada and everyone else
> is a coder.

One could say that. It wouldn't be correct, but one could say that. I, 
however, didn't say that. I said that Ada is unpopular because it's a SW 
engineering language, and most developers are coders.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63

Re: Isn't this in favour of Ada??

[Dan McLeran]

You're right, I just said it out loud to myself and it worked!

Re: Isn't this in favour of Ada??

[Erlo Haugen]

Jeffrey Carter wrote:

> Ada is a language for SW engineers; C and its offspring are languages 
> for coders. Since we allow coders to choose languages, it's not 
> surprising that they choose coders' languages.
> 
But isn't engineering (at its best) supposed to be independent of the 
language chosen?

> 
> Why don't we allow construction workers to design bridges and choose the 
> materials? Because when they fail, we lose enormous lawsuits, and that 
> more than offsets the savings obtained. Because when they fail, people 
> die in ways that attract the attention of regulators. When the same is 
> true of SW, perhaps we will see a distinction between SW engineers and 
> coders, and Ada will become more prevalent.
> 
You have a point, but most software is not like bridges, it's more like 
garden houses: if something goes wrong, it is inconvenient, but not 
fatal. I do hope that adequate engineering processes are used for 
critical software.

-- 
Erlo
-----

The statements and opinions are mine and does not
neccesarily reflect those of my employers

Re: Isn't this in favour of Ada??

[Marc A. Criley]

Erlo Haugen wrote:

> But isn't engineering (at its best) supposed to be independent of the 
> language chosen?

Nope.  Engineering is focused on implementation.  A critical component 
of software engineering therefore is implementation language.

I've ceased agreeing with the PC statement that "Good software engineers 
can write good software in any language."

Does Tiger Woods buy his clubs at Wal-Mart?  A good golfer...

Do Formula One racing teams get their tools from K-Mart?  A good mechanic...

-- Marc A. Criley
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Isn't this in favour of Ada??

[Erlo Haugen]

Marc A. Criley wrote:
> Erlo Haugen wrote:
> 
>> But isn't engineering (at its best) supposed to be independent of the 
>> language chosen?
> 
> 
> Nope.  Engineering is focused on implementation.  A critical component 
> of software engineering therefore is implementation language.
> 

So, a design dependends on implementation?

> I've ceased agreeing with the PC statement that "Good software engineers 
> can write good software in any language."
> 
> Does Tiger Woods buy his clubs at Wal-Mart?  A good golfer...
> 
> Do Formula One racing teams get their tools from K-Mart?  A good 
> mechanic...

Those are craftsmen, not designers. Naturally they choose the best 
possible tool, but the guy that designed the golf ball or car does not
need to know if the club is bought at K-Mart or if the wrench is made 
from steel or titanium.
Neither does the designer of the software neccessarily need to know 
which language is chosen to implement the design.

> 
> -- Marc A. Criley
> -- www.mckae.com
> -- DTraq - XPath In Ada - XML EZ Out


-- 
Erlo
-----

The statements and opinions are mine and does not
neccesarily reflect those of my employers

Re: Isn't this in favour of Ada??

[Dan McLeran]

But does the guy who designs the golf clubs that sell for $40 believe
that his product is pro-tour worthy?

Re: Isn't this in favour of Ada??

[Bob Spooner]

"Erlo Haugen" <"elh whirlpool terma spot com"> wrote in message
news:42e0f666$0$54741$edfadb0f@dread12.news.tele.dk...
> Marc A. Criley wrote:
> > Erlo Haugen wrote:
> >
> >> But isn't engineering (at its best) supposed to be independent of the
> >> language chosen?
> >
> >
> > Nope.  Engineering is focused on implementation.  A critical component
> > of software engineering therefore is implementation language.
> >
>
> So, a design dependends on implementation?
>
Yes, design does depend on implementation. It is impossible to completely
separate design from implementation because the design has to be built. The
design is constrained by the components available to realize the design.
Bridges are designed to use the structural members available that can
economically span the space where the bridge is to be built while supporting
the load it needs to carry.

Bob

Re: Isn't this in favour of Ada??

[Ludovic Brenta]

"Bob Spooner" <rls19@psu.edu> writes:
> "Erlo Haugen" <"elh whirlpool terma spot com"> wrote in message
> news:42e0f666$0$54741$edfadb0f@dread12.news.tele.dk...
>> Marc A. Criley wrote:
>> > Erlo Haugen wrote:
>> >
>> >> But isn't engineering (at its best) supposed to be independent
>> >> of the language chosen?
>> >
>> >
>> > Nope.  Engineering is focused on implementation.  A critical
>> > component of software engineering therefore is implementation
>> > language.
>>
>> So, a design dependends on implementation?
>
> Yes, design does depend on implementation. It is impossible to
> completely separate design from implementation because the design
> has to be built. The design is constrained by the components
> available to realize the design.  Bridges are designed to use the
> structural members available that can economically span the space
> where the bridge is to be built while supporting the load it needs
> to carry.

I agree.  Architects are physically present at the construction site
of buildings they designed.  They choose materials, construction
method, tools, and, quite often, even the workers who actually do the
job.

If you want to have a home built, and the architect never shows up at
the construction site, does this give you confidence in the architect
or the house?

-- 
Ludovic Brenta.

Re: Isn't this in favour of Ada??

[Marc A. Criley]

Erlo Haugen wrote:
> Marc A. Criley wrote:
> 
>> Nope.  Engineering is focused on implementation.  A critical component 
>> of software engineering therefore is implementation language.
>>
> So, a design dependends on implementation?

As noted in other postings, yes, design has to take the implementation 
environment into account.  E.g., does your design exploit concurrency? 
This can make a difference in your choice of Ada vs Lisp for implementation.

>> Does Tiger Woods buy his clubs at Wal-Mart?  A good golfer...
>>
>> Do Formula One racing teams get their tools from K-Mart?  A good 
>> mechanic...
> 
> Those are craftsmen, not designers.

Okay, do skyscraper architects use T-squares and pencils?  A good 
architect ...

Do commercial aircraft designers use graph paper, a French Curve, and a 
compass?  A good aircraft designer...

Remember, we're talking detailed designs sufficient to begin 
implementation, not Burt Rutan's whiteboard.

-- Marc A. Criley
-- www.mckae.com
-- DTraq - XPath In Ada -- XML EZ Out

Re: Isn't this in favour of Ada??

[Jeffrey Carter]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

Erlo Haugen wrote:
>>
> But isn't engineering (at its best) supposed to be independent of the 
> language chosen?

Hardly. A bridge is designed to work when constructed of materials with 
certain characteristics; the design is not independent of the materials.

In the SW field, we've been correcting buffer-overflow vulnerabilities 
in networking code for decades. They're the single most commonly 
exploited class of error in the code. Yet the people writing networking 
code in C today are creating new buffer-overflow errors, despite their 
knowledge of the problem and their desire not to contribute to it. It 
seems no amount of engineering can overcome the weakness of the material.

A SW engineer using C will create better SW than a coder using C, but a 
SW engineer using Ada will create better SW than a SW engineer using C. 
There was a posting here just the other day to the effect that no matter 
how carefully the poster designs his C++ code, he makes errors that he 
would not have made in Ada.

> You have a point, but most software is not like bridges, it's more like 
> garden houses: if something goes wrong, it is inconvenient, but not 
> fatal. I do hope that adequate engineering processes are used for 
> critical software.

Unfortunately, I've seen critical SW that is very badly designed, 
basically taking design techniques that work OK on a student's 300-line 
program applied to 100s of KLOC of critical code.

If there's a ditch, 2 m deep and 2 m wide, on my property between my 
house and the road, and I want to be able to get my car across it, I can 
put a couple of beams across and add a roadbed and have a bridge that 
will serve my purposes.

If I need to carry heavy trucks or span the Golden Gate of San Francisco 
Bay, this design technique is not optimum. You can build such a bridge 
across the Golden Gate. It involves a lot of piers. It will be much more 
expensive to build than a better suited design, not meet all desirable 
objectives (we'll have to give up having large ships moving in and out 
of the bay), but it will carry traffic across the gap. It will be very 
difficult and expensive to maintain.

What we have in SW are a lot of Golden Gate bridges built using design 
techniques only suitable for much smaller projects.

[-- Attachment #2: spam.vcf --]
[-- Type: text/x-vcard, Size: 177 bytes --]

begin:vcard
fn:Jeffrey Carter
n:;Jeffrey Carter
email;internet:jeffrey_r_carter-nr [commercial-at] raytheon [period | full stop] com
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: Isn't this in favour of Ada??

[Florian Weimer]

* Erlo Haugen:

> http://www.gotw.ca/publications/concurrency-ddj.htm
>
> I think so.

This is hardly new, people have been writing concurrent programs for
decades, at least on the server side.

I also fail to see Ada's advantages because Ada tasking tends to match
poorly to concurrency models supported by operating systems.  For
example, how can you add a select alternative which waits for activity
on a specific file descriptor, without introducing many pointless
context switches?

Re: Isn't this in favour of Ada??

[Larry Kilgallen]

In article <8764vcdv2f.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:

> I also fail to see Ada's advantages because Ada tasking tends to match
> poorly to concurrency models supported by operating systems.  For
> example, how can you add a select alternative which waits for activity
> on a specific file descriptor, without introducing many pointless
> context switches?

I don't know "file descriptor" as an Ada term, but presuming you mean
activity on a file, I would use the VMS Lock Manager requesting an AST
when there is activity (if I were creating an Ada implementation).

Re: Isn't this in favour of Ada??

[Marin David Condic]

I think it would be an improvement for Ada if it had a mechanism for 
defining its own interrupts and/or attaching them to various system 
signals. (Something like an exception, but where the handler ends up 
being a task entry or protected type procedure call) The mechanisms 
currently in place are typically pretty good for bare-board programming 
& connecting to some hardware interrupt, but I'd like a mechanism for 
defining my own.

One use would be to isolate a hardware interrupt behind an abstraction 
so that it can be simulated off of the target machine. If a hardware 
interrupt were translated to some abstraction like an exception (call it 
a "signal"?) I could write a "signal handler" the way I write a hardware 
interrupt handler, but then be able to run it on a PC by writing some 
low-level simulation code that triggered the "signal" rather than having 
the hardware interrupt trigger it.

MDC

Larry Kilgallen wrote:
> 
> I don't know "file descriptor" as an Ada term, but presuming you mean
> activity on a file, I would use the VMS Lock Manager requesting an AST
> when there is activity (if I were creating an Ada implementation).

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[Ed Falis]

On Mon, 18 Jul 2005 08:37:56 -0400, Marin David Condic  
<nobody@noplace.com> wrote:

> I think it would be an improvement for Ada if it had a mechanism for  
> defining its own interrupts and/or attaching them to various system  
> signals. (Something like an exception, but where the handler ends up  
> being a task entry or protected type procedure call) The mechanisms  
> currently in place are typically pretty good for bare-board programming  
> & connecting to some hardware interrupt, but I'd like a mechanism for  
> defining my own.
>

With GNAT, the RM mechanisms for handling interrupts are used for signals  
on "native" platforms, so you should be able to do something like what you  
want now.

- Ed

Re: Isn't this in favour of Ada??

[Marin David Condic]

Yes and No. Yes, you can tie an interrupt handler to a system signal as 
if it were the same as a hardware interrupt. No, in that I'd like 
another layer of abstraction. I want to separate the system dependent 
signal from the system-independent response.

Think about it this way: Interfacing to hardware these days typically 
involves three things: Reading from some special addresses, writing to 
some special addresses and responding to some hardware interrupts. So I 
might isolate my hardware beneath a package that looks like this:

package HW_Isolator is

     Some_Interrupt : signal ; -- Not really Ada - but like an exception.

     procedure Read (blah) ;
     procedure Write (blah) ;

end HW_Isolator ;

If I have some way of connecting task entries or protected type 
procedures to "Sime_Interrupt" and have a language mechanism similar to 
exception propogation (as in "raise Some_Interrupt ;") then beneath the 
package HW_Isolator I can either a) connect Some_Interrupt directly to 
the hardware or b) connect it to a simulation of the hardware running on 
a PC. My embedded code othewrwise functions identically running on the 
real processor and running in an off-line simulation.

Presumably, having the ability to do something like "raise 
Some_Interrupt ;" anywhere in your code and have it asynchronously 
trigger execution of some other logic would be of advantage beyond 
hardware isolation, but I have not given that much thought. Perhaps it 
might be viewed as "Dangerous" as well?

MDC


Ed Falis wrote:
> 
> With GNAT, the RM mechanisms for handling interrupts are used for 
> signals  on "native" platforms, so you should be able to do something 
> like what you  want now.
> 
> - Ed

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[Ed Falis]

It's certainly possible to import the "kill" routine to raise a signal.   
But of course you would have a different "interrupt" number for native and  
target, as well as needing explicit code somewhere to call kill.  So the  
code would have to be slightly different.  But I can't really think of any  
magic that could hide that.

- Ed

Re: Isn't this in favour of Ada??

[Marin David Condic]

Well, if I thought about it long enough, I could probably figure out 
some way of disconnecting the interrupt from the code it has to trigger 
using only existing Ada mechanisms. What I fear is that it would 
introduce either too much inefficiency or not provide for 
uninterruptability that may be needed by an ISR. I suppose it wouldn't 
hurt too much if you actually shielded the ISR beneath some hardware 
abstraction layer & kept it small, providing most of the "Real" work has 
to happen above it. (Let it grab data and propogate a message of some 
sort?) But then you're really not making a provision to run all of the 
software for an embedded system on some workstation platform in an 
off-line way.

It would be better with a language mechanism, but I don't know if it is 
either too complicated or of too narrow an interest to be worth a 
language update.

MDC

Ed Falis wrote:
> It's certainly possible to import the "kill" routine to raise a 
> signal.   But of course you would have a different "interrupt" number 
> for native and  target, as well as needing explicit code somewhere to 
> call kill.  So the  code would have to be slightly different.  But I 
> can't really think of any  magic that could hide that.
> 
> - Ed

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[Robert A Duff]

Marin David Condic <nobody@noplace.com> writes:

> Well, if I thought about it long enough, I could probably figure out
> some way of disconnecting the interrupt from the code it has to trigger
> using only existing Ada mechanisms. What I fear is that it would
> introduce either too much inefficiency or not provide for
> uninterruptability that may be needed by an ISR. I suppose it wouldn't
> hurt too much if you actually shielded the ISR beneath some hardware
> abstraction layer & kept it small, providing most of the "Real" work has
> to happen above it. (Let it grab data and propogate a message of some
> sort?) But then you're really not making a provision to run all of the
> software for an embedded system on some workstation platform in an
> off-line way.
> 
> It would be better with a language mechanism, but I don't know if it is
> either too complicated or of too narrow an interest to be worth a
> language update.

The problem you're talking about is "How to deal with cases where you
need to write different code for different platforms."  If the language
is well designed, and the compilers aren't too buggy, this will happen
fairly rarely.  Interrupt handling is inherently platform specific, so
this is one case where you'll need platform-specific code.  The usual
solutions are to use a preprocessor of some sort, or to write different
versions of the same source file, and have the build process select
among them.

So I think no interrupt-specific language mechanism is warranted here.

I agree with you that it would be nice to have a way to trigger an
interrupt under program control.

- Bob

Re: Isn't this in favour of Ada??

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> I agree with you that it would be nice to have a way to trigger an
> interrupt under program control.

_If_ you are running VxWorks on a VME-based system, you can call
sysBusIntGen().

Re: Isn't this in favour of Ada??

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > I agree with you that it would be nice to have a way to trigger an
> > interrupt under program control.
> 
> _If_ you are running VxWorks on a VME-based system, you can call
> sysBusIntGen().

I meant an Ada feature to trigger an interrupt.  Yes, on most systems,
there's a way to do it.  It would be nice to have a portable Ada name
for this procedure.

- Bob

Re: Isn't this in favour of Ada??

[Marin David Condic]

Besides, this can only work if you have an operating system. If you 
*are* the operating system, you'd have to do something to bump the 
hardware to make an interrupt happen and this may or may not be possible 
in all cases. This is why I say if Ada had something like a "signal" 
entity that is typically tied to an interrupt, but (since its an Ada 
thing) can be triggered by some Ada mechanism, then you've got the 
problem solved. You could probably "Roll Your Own" - but I'm not sure 
how to do that and still utilize Ada's normal mechanisms for interrupt 
processing.

MDC

Robert A Duff wrote:
> 
> I meant an Ada feature to trigger an interrupt.  Yes, on most systems,
> there's a way to do it.  It would be nice to have a portable Ada name
> for this procedure.
> 
> - Bob

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[Robert A Duff]

Marin David Condic <nobody@noplace.com> writes:

> Besides, this can only work if you have an operating system.

It *can* work without an operating system.

>... If you
> *are* the operating system, you'd have to do something to bump the
> hardware to make an interrupt happen

Right.

>... and this may or may not be possible
> in all cases.

It's possible for many interrupts on many systems, with or without an
OS.  Many machines have a "trigger interrupt" instruction.

I wouldn't insist that the "trigger interrupt" Ada routine be completely
portable.  After all, the names of the interrupts are inherently
nonportable.  It's still useful to have a standard procedure, for those
systems where it can work.  I'd define it to raise an exception for
interrupts that cannot be triggered.uun

>... This is why I say if Ada had something like a "signal"
> entity that is typically tied to an interrupt, but (since its an Ada
> thing) can be triggered by some Ada mechanism, then you've got the
> problem solved. You could probably "Roll Your Own" - but I'm not sure
> how to do that and still utilize Ada's normal mechanisms for interrupt
> processing.

I think such a signal mechanism would add some inefficiency.
Perhaps not much, but when you're using interrupts on a bare
machine, you want to be as close to the metal as possible,
and Ada's current design allows for that.

I suspect that rolling your own will give better results, because then
the programmer is in charge of the efficiency tradeoffs, and the
programmer can take advantage of the particular systems of interest,
whereas the language designer has to be portable to pretty much every
machine under the Sun.

- Bob

Re: Isn't this in favour of Ada??

[Marin David Condic]

Yes, interrupt handling is platform specific, but since Ada found a way 
to connect a protected procedure to an interrupt, it would seem that 
some similar mechanism could be invented to translate a platform 
specific interrupt into a portable representation. I don't see how this 
wouldn't be in the general spirit of Ada - especially if I can hide the 
hardware connection in a package BODY so it can be substituted for 
different platforms. (Or do I need to raise the whole issue of 
conditional compilation again? ;-)

It doesn't seem like a big leap to have some language defined "signal" 
abstraction that could be either hardware triggered, OS triggered or 
software triggered so that the protected procedure could do what it is 
currently doing to connect to an interrupt (connecting to the "signal" 
abstraction instead), but you could hide the triggering mechanism under 
a package body somewhere.

I'm not looking to avoid having to do some code substitution between a 
target machine and a simulation. What I'm looking for is a mechanism 
that lets you hide the SOURCE of the interrupt in a package BODY so that 
the embedded executive developer and the workstation simulation 
developer can both work from a common specification and all we have to 
do to get off the target and on to the simulation is substitute one 
package body. With Ada as it stands, I'm not sure I can do that without 
some significant gyrations. A language defined "signal" would seem to 
provide a simple mechanism for doing that.

MDC

Robert A Duff wrote:
> 
> The problem you're talking about is "How to deal with cases where you
> need to write different code for different platforms."  If the language
> is well designed, and the compilers aren't too buggy, this will happen
> fairly rarely.  Interrupt handling is inherently platform specific, so
> this is one case where you'll need platform-specific code.  The usual
> solutions are to use a preprocessor of some sort, or to write different
> versions of the same source file, and have the build process select
> among them.
> 
> So I think no interrupt-specific language mechanism is warranted here.
> 
> I agree with you that it would be nice to have a way to trigger an
> interrupt under program control.
> 
> - Bob

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Isn't this in favour of Ada??

[Robert I. Eachus]

Marin David Condic wrote:

> It doesn't seem like a big leap to have some language defined "signal" 
> abstraction that could be either hardware triggered, OS triggered or 
> software triggered so that the protected procedure could do what it is 
> currently doing to connect to an interrupt (connecting to the "signal" 
> abstraction instead), but you could hide the triggering mechanism under 
> a package body somewhere.
> 
> I'm not looking to avoid having to do some code substitution between a 
> target machine and a simulation. What I'm looking for is a mechanism 
> that lets you hide the SOURCE of the interrupt in a package BODY so that 
> the embedded executive developer and the workstation simulation 
> developer can both work from a common specification and all we have to 
> do to get off the target and on to the simulation is substitute one 
> package body. With Ada as it stands, I'm not sure I can do that without 
> some significant gyrations. A language defined "signal" would seem to 
> provide a simple mechanism for doing that.

Hmmm...  If I wanted to do this in a platform independent manner, I'd 
have a package containing an enumeration type that provided the 
interrupt names.  If you prefer, you could have an integer type with 
deferred constants for some common useful names.

Also in the package would be a generic package with two procedures for 
binding and unbinding the interrupt to a task or protected object entry. 
  The choice of generic formals I leave up to you.  I'd go for a formal 
parameterless procedure for the action to be called.  That lets you use 
a procedure in a protected object.  And I would have the package body 
maintain a stack of bindings that resides in the non-generic enclosing 
package.  However, I would have the unbind routine raise an error if it 
is not from the generic instance that did the binding.  Oh, and the 
generic body should use finalization to insure that when the scope in 
which the generic package is instantiated is left, the interrupt is 
unbound if necessary.

At the other end of the spectrum would be an implementation where 
instantiating the generic did the binding, and the unbinding occurs when 
the enclosing scope is left. So the generic takes two 
(generic)parameters an interrupt name or number and the procedure or 
entry to be called.  Not as powerful an abstraction, but easier to use. 
  In practice though, most interrupt bindings will have the same scope 
as the main program...

RIE

Re: Isn't this in favour of Ada??

[Florian Weimer]

* Larry Kilgallen:

> In article <8764vcdv2f.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
>
>> I also fail to see Ada's advantages because Ada tasking tends to match
>> poorly to concurrency models supported by operating systems.  For
>> example, how can you add a select alternative which waits for activity
>> on a specific file descriptor, without introducing many pointless
>> context switches?
>
> I don't know "file descriptor" as an Ada term, but presuming you mean
> activity on a file, I would use the VMS Lock Manager requesting an AST
> when there is activity (if I were creating an Ada implementation).

But my point was that this has to be done by the implementor.  It is
something that is hard to resolve at a library level (unless you are
willing to take the costs of a few additional context switches, of
course).

Re: Isn't this in favour of Ada??

[Larry Kilgallen]

In article <87ll3hyi14.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> * Larry Kilgallen:
> 
>> In article <8764vcdv2f.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> I also fail to see Ada's advantages because Ada tasking tends to match
>>> poorly to concurrency models supported by operating systems.  For
>>> example, how can you add a select alternative which waits for activity
>>> on a specific file descriptor, without introducing many pointless
>>> context switches?
>>
>> I don't know "file descriptor" as an Ada term, but presuming you mean
>> activity on a file, I would use the VMS Lock Manager requesting an AST
>> when there is activity (if I were creating an Ada implementation).
> 
> But my point was that this has to be done by the implementor.  It is
> something that is hard to resolve at a library level (unless you are
> willing to take the costs of a few additional context switches, of
> course).

By "implementor" I presume you mean the person who builds an Ada
compiler and runtime system for a particular operating system.
The fact that it is hard to build a compiler is not my problem
unless I am trying to build the compiler myself.

Re: Isn't this in favour of Ada??

[Florian Weimer]

* Larry Kilgallen:

>>>> I also fail to see Ada's advantages because Ada tasking tends to match
>>>> poorly to concurrency models supported by operating systems.  For
>>>> example, how can you add a select alternative which waits for activity
>>>> on a specific file descriptor, without introducing many pointless
>>>> context switches?
>>>
>>> I don't know "file descriptor" as an Ada term, but presuming you mean
>>> activity on a file, I would use the VMS Lock Manager requesting an AST
>>> when there is activity (if I were creating an Ada implementation).
>> 
>> But my point was that this has to be done by the implementor.  It is
>> something that is hard to resolve at a library level (unless you are
>> willing to take the costs of a few additional context switches, of
>> course).
>
> By "implementor" I presume you mean the person who builds an Ada
> compiler and runtime system for a particular operating system.
> The fact that it is hard to build a compiler is not my problem
> unless I am trying to build the compiler myself.

The original claim in this thread was that Ada is particularly
suitable to the concurrency challenges ahead of us (I don't believe
that there are any fundamentally new challenges, but let's assume that
there are).  However, in order to create scalable applications, you
have to use some features of today's operating systems, for example
I/O multiplexing.  

I am not aware of any Ada implementation which integrates I/O
multiplexing with tasks. Therefore, it seems to me that Ada's tasking
is a completely useless burden when developing concurrent applications
on mainstream operating systems.  Usually, you have to figure out how
to work around it realiably, so that the run-time library continues to
work.

Re: Isn't this in favour of Ada??

[Larry Kilgallen]

In article <877jf02ud1.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:

> I am not aware of any Ada implementation which integrates I/O
> multiplexing with tasks. Therefore, it seems to me that Ada's tasking
> is a completely useless burden when developing concurrent applications
> on mainstream operating systems.  Usually, you have to figure out how
> to work around it realiably, so that the run-time library continues to
> work.

The DEC Ada package Tasking_Services provides a model for those
who want to avoid setting up their own AST entries for calling
$QIO and similar services.

Re: Isn't this in favour of Ada??

[tmoran]

> I am not aware of any Ada implementation which integrates I/O
> multiplexing with tasks. Therefore, it seems to me that Ada's tasking
> is a completely useless burden when developing concurrent applications
> on mainstream operating systems.  Usually, you have to figure out how
> to work around it realiably, so that the run-time library continues to
> work.
   There's an OS called Windows which, while you may not like it, cannot
be called non-mainstream.  It's mostly based on polling, which works
just fine with tasks.  Claw has been working fine that way for nearly
a decade now.

Re: Isn't this in favour of Ada??

[Pascal Obry]

Florian Weimer <fw@deneb.enyo.de> writes:

> The original claim in this thread was that Ada is particularly
> suitable to the concurrency challenges ahead of us (I don't believe
> that there are any fundamentally new challenges, but let's assume that
> there are).  However, in order to create scalable applications, you
> have to use some features of today's operating systems, for example
> I/O multiplexing.  

And ??? Isn't this like saying that C++ is not suitable to the concurrency
challenges because it does not support IO multiplexing? Just use the same
library with Ada that you use with C++ for the IO. Reading the C++ RM you
certainly won't find a single work about IO multiplexing.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Isn't this in favour of Ada??

[Pascal Obry]

Pascal Obry <pascal@obry.net> writes:

> And ??? Isn't this like saying that C++ is not suitable to the concurrency
> challenges because it does not support IO multiplexing? Just use the same
> library with Ada that you use with C++ for the IO. Reading the C++ RM you
> certainly won't find a single work about IO multiplexing.

Rereading your mail I see that it was related to tasking and IO multiplexing
is related to threading. So I withdraw my comments.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Isn't this in favour of Ada??

[Dmitry A. Kazakov]

On Fri, 05 Aug 2005 18:58:50 +0200, Florian Weimer wrote:

> The original claim in this thread was that Ada is particularly
> suitable to the concurrency challenges ahead of us (I don't believe
> that there are any fundamentally new challenges, but let's assume that
> there are).  However, in order to create scalable applications, you
> have to use some features of today's operating systems, for example
> I/O multiplexing.  

Which is a case of more general waiting for multiple events. The problem is
that multiple-wait is a too low level mechanism. It is not very clear how
to map it on entry calls and accept.
 
> I am not aware of any Ada implementation which integrates I/O
> multiplexing with tasks. Therefore, it seems to me that Ada's tasking
> is a completely useless burden when developing concurrent applications
> on mainstream operating systems.  Usually, you have to figure out how
> to work around it realiably, so that the run-time library continues to
> work.

I disagree. Multitasking is more than just multiplexed I/O. If you look at
Windows (sort of mainstream) you find dozens of calls starting a thread.
Among them only 1 or 2 are actually usable. The synchronization mechanisms
Windows offers are all too low level. So for our C++ project of a
middleware (heavily multitasking), we end up with developing a library that
mimics Ada's rendezvous.

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

Re: Isn't this in favour of Ada??

[Maciej Sobczak]

Erlo Haugen wrote:
> http://www.gotw.ca/publications/concurrency-ddj.htm
> 
> I think so.

I don't think so. I mean - the article is neutral with regard to Ada, 
and not only because it does not mention "Ada" at all.

The article is about the fact that future hardware platforms will tend 
to have more and more parallelism, no matter whether this will be used 
by software or not. Actually, this happens already, even on popular 
desktop platforms.
The problem that you seem to forget about is that all the factors that 
are used today for choosing the language (some factors are technical, 
some not, but that does not matter) will be still in use tomorrow. For 
example, if some project chooses Java, it does so independent of whether 
the program will be running on Hyper Threading processor or not - so the 
increased concurrency capabilities of the target platform has no impact 
on the language chosen for implementation. In general, programmers will 
not rush to change their languages just because the multicore CPUs will 
become prevalent. This article is therefore about raising the awareness 
of programmers that concurrency is the only way to benefit from new 
hardware, which is very far from saying that people should move to 
another language - be it Ada or whatever else. And since the author is 
involved in the C++ standardization process, I'd rather read this 
article as a "good-source" prediction that more effort will be put into 
standardizing the relation between C++ and multithreading (which already 
happens).

The *only* way it could be in favour of Ada is to reuse the experience 
of the Ada community when defining threading for C++ (I'm not sure 
whether this will be the case or not), but I don't think that this kind 
of "favour" is what you really mean. ;)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Isn't this in favour of Ada??

[Erlo Haugen]

Maciej Sobczak wrote:
> Erlo Haugen wrote:
> 
>> http://www.gotw.ca/publications/concurrency-ddj.htm
>>
>> I think so.
> 
> 
> I don't think so. I mean - the article is neutral with regard to Ada, 
> and not only because it does not mention "Ada" at all.
> 
> The article is about the fact that future hardware platforms will tend 
> to have more and more parallelism, no matter whether this will be used 
> by software or not. Actually, this happens already, even on popular 
> desktop platforms.
> The problem that you seem to forget about is that all the factors that 
> are used today for choosing the language (some factors are technical, 
> some not, but that does not matter) will be still in use tomorrow. For 
> example, if some project chooses Java, it does so independent of whether 
> the program will be running on Hyper Threading processor or not - so the 
> increased concurrency capabilities of the target platform has no impact 
> on the language chosen for implementation. In general, programmers will 
> not rush to change their languages just because the multicore CPUs will 
> become prevalent. This article is therefore about raising the awareness 
> of programmers that concurrency is the only way to benefit from new 
> hardware, which is very far from saying that people should move to 
> another language - be it Ada or whatever else. And since the author is 
> involved in the C++ standardization process, I'd rather read this 
> article as a "good-source" prediction that more effort will be put into 
> standardizing the relation between C++ and multithreading (which already 
> happens).
> 
> The *only* way it could be in favour of Ada is to reuse the experience 
> of the Ada community when defining threading for C++ (I'm not sure 
> whether this will be the case or not), but I don't think that this kind 
> of "favour" is what you really mean. ;)
> 
> 
What i meant to say was that Ada already has the features needed to take 
advantage of this increasing parallelism, be it hyperthreading og 
multiple processors, and doing it in a portable way. Threading 
possibilities are already supplied by most OSes, but by incorporating it 
as a language standard, it becomes portable.

-- 
Erlo
-----

The statements and opinions are mine and does not
neccesarily reflect those of my employers

Re: Isn't this in favour of Ada??

[Maciej Sobczak]

Erlo Haugen wrote:

> What i meant to say was that Ada already has the features

Yes, I understand this. But standardizing threading features in other 
languages means simply that Ada can lose its competetive edge in this 
very aspect (portability of concurrent programs). That's why I don't 
really think that the article in question is "in favour" of Ada.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Isn't this in favour of Ada??

[Erlo Haugen]

Maciej Sobczak wrote:
> Erlo Haugen wrote:
> 
>> What i meant to say was that Ada already has the features
> 
> 
> Yes, I understand this. But standardizing threading features in other 
> languages means simply that Ada can lose its competetive edge in this 
> very aspect (portability of concurrent programs). That's why I don't 
> really think that the article in question is "in favour" of Ada.
> 
> 
Oh, I see. That might be correct, but for now it seems that Ada is 
leading the pack.

-- 
Erlo
-----

The statements and opinions are mine and does not
neccesarily reflect those of my employers

Re: Isn't this in favour of Ada??

[Alex R. Mosteo]

Erlo Haugen wrote:
> Maciej Sobczak wrote:
> 
>> Erlo Haugen wrote:
>>
>>> What i meant to say was that Ada already has the features
>>
>>
>>
>> Yes, I understand this. But standardizing threading features in other 
>> languages means simply that Ada can lose its competetive edge in this 
>> very aspect (portability of concurrent programs). That's why I don't 
>> really think that the article in question is "in favour" of Ada.
>>
>>
> Oh, I see. That might be correct, but for now it seems that Ada is 
> leading the pack.

OpenMP is pushing hard. At least I heard of it a lot, and seems to be 
pretty standard when it comes to multithreading with C/C++. This edge in 
Ada may be very well already lost.

Re: Isn't this in favour of Ada??

[Pascal Obry]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> OpenMP is pushing hard. At least I heard of it a lot, and seems to be pretty
> standard when it comes to multithreading with C/C++. This edge in Ada may be
> very well already lost.

Have you looked at an OpenMP C++ enabled application ? OpenMP is a quite
intrusive technology (adding lot of directives in comment) this makes the
code again less readable. I agree that OpenMP is pushing hard, I'm sure it
will gain a very good part of the market... this is just sad when you know the
Ada tasking model. We can also talk about MPI compared to the distributed
annex :(

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Isn't this in favour of Ada??

[Tassilo v. Parseval]

Also sprach Pascal Obry:

> "Alex R. Mosteo" <devnull@mailinator.com> writes:
>
>> OpenMP is pushing hard. At least I heard of it a lot, and seems to be pretty
>> standard when it comes to multithreading with C/C++. This edge in Ada may be
>> very well already lost.
>
> Have you looked at an OpenMP C++ enabled application ? OpenMP is a quite
> intrusive technology (adding lot of directives in comment) this makes the
> code again less readable. I agree that OpenMP is pushing hard, I'm sure it
> will gain a very good part of the market... this is just sad when you know the
> Ada tasking model. We can also talk about MPI compared to the distributed
> annex :(

I don't think that Ada tasks and MPI are comparable. MPI is mainly used
in the fields of supercomputing. You would certainly not use it as a
fork or threads replacement (incidentally, the 1.x standard of MPI did
not allow to create processes dynamically) because it would just be too
painful.

On the other hand it offers things not present in Ada tasks. MPI has its
own datatypes that allow you to specify in detail which parts of a
data-structure to send to another process, where the appropriate
conversions are done by MPI's pack routines. If you have a matrix with
rank 100,000 you don't want to share it all and in Ada you'd explicitely
have to take precautions against that.

Furthermore, MPI allows you to write a program that does a calculation
in parallel on your computer and, say, NEC's earth simulator because
data-exchange between processors can happen over TCP/IP. So MPI really
is a way to distribute one application across a huge distributed system
involving workstations that can be anywhere on the internet.

Also, there are MPI bindings for Ada which wouldn't be the case if those
two had the same niches in mind.

Tassilo
-- 
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);

Re: Isn't this in favour of Ada??

[Adrien Plisson]

Tassilo v. Parseval wrote:
> I don't think that Ada tasks and MPI are comparable. MPI is mainly used
> in the fields of supercomputing. You would certainly not use it as a
> fork or threads replacement (incidentally, the 1.x standard of MPI did
> not allow to create processes dynamically) because it would just be too
> painful.

the Ada tasking model may be regarded as a form of MPI, when MPI is 
taken in its broader form of "message passing interface".

but MPI taken in its narrower form of "MPI standard 
<http://www-unix.mcs.anl.gov/mpi/>" is more closely related to Ada 
Distributed Annex, with which it shares a lot of features, including 
all those cited below:

> On the other hand it offers things not present in Ada tasks. MPI has its
> own datatypes that allow you to specify in detail which parts of a
> data-structure to send to another process, where the appropriate
> conversions are done by MPI's pack routines. If you have a matrix with
> rank 100,000 you don't want to share it all and in Ada you'd explicitely
> have to take precautions against that.
> 
> Furthermore, MPI allows you to write a program that does a calculation
> in parallel on your computer and, say, NEC's earth simulator because
> data-exchange between processors can happen over TCP/IP. So MPI really
> is a way to distribute one application across a huge distributed system
> involving workstations that can be anywhere on the internet.

all this should be posible with the Ada distributed annex (annex E of 
the Ada 95 Reference Manual).

a free implementation of this annex for the GNAT compiler is available 
under the name "Glade" (which is not to be confused with the Gtk+ GUI 
builder).

> Also, there are MPI bindings for Ada which wouldn't be the case if those
> two had the same niches in mind.

strange enough when one knows about annex E. i think it exists for 
inter-operability between softwares written using different languages. 
(Annex E is kinda Ada'ish).

(side note: shouldn't PolyORB provide a personality which would allow 
an Ada Annex E enabled application to inter-operate with a MPI enabled 
amplication ?)

-- 
rien

Re: Isn't this in favour of Ada??

[Jerome Hugues]

In article <42e4e8ea$0$3948$ba620e4c@news.skynet.be>, Adrien Plisson wrote:

>> Also, there are MPI bindings for Ada which wouldn't be the case if those
>> two had the same niches in mind.
> 
> strange enough when one knows about annex E. i think it exists for 
> inter-operability between softwares written using different languages. 
> (Annex E is kinda Ada'ish).

I'm not sure this was the main goal of annex E, perhaps an Ada
"historian" can confirm. Annex B (Interface to Other Languages) seems
more relevant for this topic.

> (side note: shouldn't PolyORB provide a personality which would allow 
> an Ada Annex E enabled application to inter-operate with a MPI enabled 
> amplication ?)

PolyORB *c*ould, the "only" point is to provide the corresponding
protocol personality (if MPI defines its own protocol), and (I
suppose) some way to map Ada calls onto MPI functions (and
vice-versa). I'm not an MPI expert.

There already exist mappings for CORBA <=> DSA (quite natural in most
cases, ses Quinot's paper on CIAO), CORBA/MOM (requires some
thinking), so why not for DSA/MPI.

*sh*ould is another question .. but we welcome all new contributors
onboard ;)

-- 
Jerome

Re: Isn't this in favour of Ada??

[Adrien Plisson]

Jerome Hugues wrote:

> In article <42e4e8ea$0$3948$ba620e4c@news.skynet.be>, Adrien Plisson wrote: 
> 
>>strange enough when one knows about annex E. i think it exists for 
>>inter-operability between softwares written using different languages. 
>>(Annex E is kinda Ada'ish).
> 
> I'm not sure this was the main goal of annex E, perhaps an Ada
> "historian" can confirm. Annex B (Interface to Other Languages) seems
> more relevant for this topic.

well, technically, you are right: the goal of annex B is interfacing 
software components written in Ada with other components written in 
other languages. Annex E has nothing to do with this case.

when re-reading my sentence, i see i should have stated it this way: 
"i think that _MPI bindings for Ada_ exists for inter-operability 
between woftwares written using different languages".

this means making softwares written in different languages, including 
Ada, communicate through MPI, on a cluster for example. my point was 
that the Ada Distributed Annex is of no-help when components written 
in other languages are involved: it is specifically tailored for Ada 
softwares.

which leads us directly to my last point: making ada distributed 
softwares written using annex E communicate with other distributed 
softwares written using MPI could be possible through the use of a 
middleware (like PolyORB) if that middleware is able to translate back 
and forth between DSA and MPI.

>>(side note: shouldn't PolyORB provide a personality which would allow 
>>an Ada Annex E enabled application to inter-operate with a MPI enabled 
>>amplication ?)
> 
> PolyORB *c*ould, the "only" point is to provide the corresponding
> protocol personality (if MPI defines its own protocol), and (I
> suppose) some way to map Ada calls onto MPI functions (and
> vice-versa). I'm not an MPI expert.

it was just a suggestion thrown here for free. i'm no expert in the 
field of distributed softwares. i also think it *c*ould be possible, 
but i don't know if the PolyORB development team ever thought of this.

> *sh*ould is another question .. but we welcome all new contributors
> onboard ;)

it is with deep regret that i have have to announce that, 
unfortunately, due to the lack of research in time-warping and the 
impossibility to extend free time (which might not be free as in "free 
beer"), this new contributor won't be me.

-- 
rien

Re: Isn't this in favour of Ada??

[Jerome Hugues]

In article <42e50b87$0$30716$ba620e4c@news.skynet.be>, Adrien Plisson wrote:

> it was just a suggestion thrown here for free. i'm no expert in the 
> field of distributed softwares. i also think it *c*ould be possible, 
> but i don't know if the PolyORB development team ever thought of this.

Speaking for myself (as one contributor of the PolyORB project,
working on it as part of my PhD), I've already thought about it. 

But I do not know MPI enough to be sure this is something I want to
do, or that would be used by a lot of people.

-- 
Jerome

Re: Isn't this in favour of Ada??

[Tassilo v. Parseval]

Also sprach Jerome Hugues:

> In article <42e50b87$0$30716$ba620e4c@news.skynet.be>, Adrien Plisson wrote:
>
>> it was just a suggestion thrown here for free. i'm no expert in the 
>> field of distributed softwares. i also think it *c*ould be possible, 
>> but i don't know if the PolyORB development team ever thought of this.
>
> Speaking for myself (as one contributor of the PolyORB project,
> working on it as part of my PhD), I've already thought about it. 
>
> But I do not know MPI enough to be sure this is something I want to
> do, or that would be used by a lot of people.

It might be. The Ada folks just have to keep in mind that it could
attract the "wrong" people: physicists, mathematicians and the lot.
Certainly not people accused of being strong in the fields of
software-engineering. ;-)

Tassilo
-- 
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);

Re: Isn't this in favour of Ada??

[Pascal Obry]

"Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes:

> I don't think that Ada tasks and MPI are comparable. MPI is mainly used

I'm not talking about Ada tasking. I'm talking about Ada distributed
annex.

> in the fields of supercomputing. You would certainly not use it as a
> fork or threads replacement (incidentally, the 1.x standard of MPI did
> not allow to create processes dynamically) because it would just be too
> painful.

Indeed, I'm certainly not saying that one should use Ada tasks + fork in a
replacement of MPI :)

> Furthermore, MPI allows you to write a program that does a calculation
> in parallel on your computer and, say, NEC's earth simulator because
> data-exchange between processors can happen over TCP/IP. So MPI really
> is a way to distribute one application across a huge distributed system
> involving workstations that can be anywhere on the internet.

Idem for Ada *distributed* annex.

> Also, there are MPI bindings for Ada which wouldn't be the case if those
> two had the same niches in mind.

That's not a proof! It could mean that somebody wanted to use Ada in a larger
project where C++/MPI was used for example.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Isn't this in favour of Ada??

[Tassilo v. Parseval]

Also sprach Pascal Obry:

> "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes:
>
>> I don't think that Ada tasks and MPI are comparable. MPI is mainly used
>
> I'm not talking about Ada tasking. I'm talking about Ada distributed
> annex.

My apologies, I must have missed that part. However...

>> Furthermore, MPI allows you to write a program that does a calculation
>> in parallel on your computer and, say, NEC's earth simulator because
>> data-exchange between processors can happen over TCP/IP. So MPI really
>> is a way to distribute one application across a huge distributed system
>> involving workstations that can be anywhere on the internet.
>
> Idem for Ada *distributed* annex.

Annex E doesn't say much about these things. It's normative in that it
says that RPC is to be used (with message passing remaining, at least,
an option) and puts some requirements on the three different library
units involved.

This whole annex is merely a few pages. Compare that with MPI 2.0 which
consists of 370 pages. It defines in great depth all the data-types that
an MPI conformant systems needs to implement and the whole interface.
That makes MPI extremely portable.

Whereas Ada's distributed annex leaves almost everything up to the
actual implementation.

>> Also, there are MPI bindings for Ada which wouldn't be the case if those
>> two had the same niches in mind.
>
> That's not a proof! It could mean that somebody wanted to use Ada in a larger
> project where C++/MPI was used for example.

Maybe. But the mere fact that you can write a small MPI application in
Ada and connect it to an already existing one running elsewhere speaks
in favour of MPI. MPI is huge in that in certain fields it is used
almost exclusively, owing to the fact that its standard is so
comprehensive and non-ambiguous.

Tassilo
-- 
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);

Re: Isn't this in favour of Ada??

[Pascal Obry]

"Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes:

> This whole annex is merely a few pages. Compare that with MPI 2.0 which
> consists of 370 pages. It defines in great depth all the data-types that
> an MPI conformant systems needs to implement and the whole interface.

Ada Annex-E says nothing about data type because it supports all the Ada data
types described elsewhere.

> That makes MPI extremely portable.

Agreed.

> Maybe. But the mere fact that you can write a small MPI application in
> Ada and connect it to an already existing one running elsewhere speaks
> in favour of MPI. MPI is huge in that in certain fields it is used
> almost exclusively, owing to the fact that its standard is so
> comprehensive and non-ambiguous.

Agreed too. For interoperability reasons it is certainly good to
consider MPI since it is widly used in HPC. But I'm also positive to
say that using Ada Distributed Annex is a good alternative to MPI if
interoperability is not an issue.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Isn't this in favour of Ada??

[Georg Bauhaus]

Alex R. Mosteo wrote:

> OpenMP is pushing hard. At least I heard of it a lot, and seems to be 
> pretty standard when it comes to multithreading with C/C++. This edge in 
> Ada may be very well already lost.
> 

Except that handling data shared by more than one thread using pragma
annotations (OpenMP), and (Ada) a concurrency model built into the type
system, scope rules, ... are two very different things IMHO.
OpenMP, another kludge to be added to C, C++, and Fortran?
If at least they could consider µC++.


"A program that consists of an original program, annotated with OpenMP
directives." A flexible and powerful solution indeed, you assemble
a concurrent program with omp start/end directives around sequences of
statements. If my understanding is correct, then OpenMP offers building
blocks for parallel programs, to be used via libraries.

"throw() must not violate the entry/exit criteria." ...

Is OpenMP going to be another instance of what Meyer has described
as "debugging an application into existence", only more challenging?