Re: Feasibility of using Ada in new development

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

>>>>> "WN" == Wojtek Narczynski <wojtek@power.com.pl> writes:

<snip>

    WN> Final example, I am sincerely interested in the resolution, you may
    WN> perceive it as a challenge for an Ada zealot:
    WN> - http://state-threads.sourceforge.net/ how would you do this in Ada
    WN> (thread = task)? http://citeseer.ist.psu.edu/681845.html describes why
    WN> I would want this.

Its was shown years ago by researchers from IBM, that switching
threads only when the application was in a well-defined state gave
opportuninty for considerable optimization of thread switching, so the
basic idea is sound.

But I am not convinced that the advantages of using state-threads are
much more than you would get from just using another task dispatching
policy in Ada. Thre trouble with that is of course that such a policy
is not part of the Ada standard. On the other hand, state-threads
aren't a standard either.

I think just switching from a the native threads interface in GNAT to
the user-space POSIX version should give you an order of magnitude
better performance wrt. task switching time, at least it did last time
I tried it. You also will get some of the drawbacks, like your whole
program will block on some OS calls.

Fundamentally, what you need is fast task switching and and if you
want to minimize the number of locks, non-preemptive scheduling.

I believe that at least one Ada vendor (Green Hills) can supply
you with a version which supports non-preemptive scheduling.

I also think that it is possible to compile the FSU Pthreads library
in such a way that it will give you non-preemptive scheduling. Whether
the GNAT runtime would still work with a modified FSU pthreads, I
cannot say.

    WN> I really don't know wether to start a six months and up, high risk,
    WN> project to modify the GNAT runtime, or just use this library in C.

I would think using any library derived from Netscape *IS* high risk.
It is easily the most bug-ridden program on my desktop.

Also, do not believe that when using non-preemptive scheduling that
you can get rid of *ALL* locks. Depending on you application, there
will usually be locks which must be held between activations of your
thread.

    WN> Regards,
    WN> Wojtek

-- 
   C++: The power, elegance and simplicity of a hand grenade.