Re: [announcement] SYSAPI and SYSSVC for Windows

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Ekkehard Morgenstern wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> No the problem is that time slicing functions in some different way. We
>> have heavily multitasking data acquisition and control applications
>> running under Windows. When customers expressed a cautious desire to
>> "take a look at", we discovered that things worked just fine under NT,
>> performed worse under 2k. Under XP we already needed to play with
>> thread's priorities to make it working...
> 
> What kind of stuff are you doing?

The thing I mentioned was a large automation system for a roller
dynamometer.

> Why not use message queues and asynchronous I/O internally and stuff?

It uses all that. The problem is [very simplified] that two threads which
require approximately same number of time quants per second, get it under
NT, while under XP the balance looks like 8/1, causing stalling of a queue.
Boosting the priority of some of the threads solves the problem, although
leaving a feeling of great discomfort. We have no time for any scientific
researches concerning XP, so we are just waiting for the Service Pack 1000,
Longhorn, Devilhoof, whatsoever! (:-))

> Even Win 2000 can be amazingly fast (XP even more).

You mean, amazingly to what one would expect from a MS product! (:-))

>> I do not count the stuff you mention as a part of OS. And instead of
>> useless job scheduling and fancy visual effects, they'd better make DLLs
>> and drivers being notified upon process termination or at least
>> ReleaseMutexAndWaitForSingleObject...
> 
> Huh?? DLLs ARE notified upon process termination. The DLL has to have a
> DllMain() function that receives parameters like DLL_PROCESS_ATTACH and
> DLL_PROCESS_DETACH and DLL_THREAD_ATTACH and DLL_THREAD_DETACH.
> 
> However, you must not terminate the process forcefully. Under some
> conditions, the DLL cleanup is not done properly, but this is documented
> well in the Windows API documentation.

Yes, this is what I mean - better reboot the box, if a process crashes, and
never ever think to use TerminateProcess...
 
> A desire in a "ReleaseMutexAndWaitForSingleObject" function smells
> like bad multithreading design to me. What is it that you want to achieve
> with that?

To avoid race conditions. Because, it is c.l.a, it is worth to mention how
Ada did solve this, it introduced the requeue-statement.

>> > Also, wanting features from other languages in Ada might not be the
>> > right solution. Ada has its own concept. We'll see what the Ada20xx
>> > committee will decide upon.
>> 
>> It is not about features of other languages. I know no language which
>> consistently implements ADT (and OO)
> 
> In C++ you can use pure virtual classes to provide abstract data types.
> And in Java, you use interfaces.

I meant ADT in the sense of user-defined types. They could be abstract or
not. All languages have problems with that. For example, in Ada you cannot:

   type Handle is private access Object;
private
   type Handle is record -- Private implementation of an access type
      ...
   end record;

>> You need not to advocate for Ada in c.l.a! (:-)) But the example is
>> unfortunate, both Ada and C++ do assignment wrong, IMO.
> 
> How would you like assignment to be handled?

There is no agreement on that. If you ask my opinion, then without much
tinking, about it...

1. User-definable assignment for all types
2. Separated from copy constructor
2. Deriving assignment from a copy constructor on demand
3. Defining the copy constructor through assignment, also on demand
4. An ability to specify the contract so that the semantics of the copy
constructor and assignment are compatible, when not 2 or 3
5. It should be dispatching in both arguments
6. Disallowing assignment in derived types on demand
7. Access to the target before it gets finalized
...

>> > exceptions in C++, I have to create a real exception class, while in
>> > Ada I can simply declare it, which greatly speeds up implementation of
>> > code supporting exceptions.
>> 
>> Right. But there are also numerous problems with exceptions in Ada. In
>> general they fall out of the type system. I do not think as many do, that
>> C++'s mapping exception->type is good. Ada's exception->object is OK to
>> me. But I wished to have exceptions a true enumeration type, to have
>> ranges. And thus extensible enumeration types, and of course a way to put
>> exceptions in the contract of a subprogram.
> 
> Call me a heretic, but I think how Ada handles exceptions is cool! ;)
> 
> I'm glad I don't have to specify exceptions in the function/procedure
> contract. Imagine how that would blow the spec declarations out of
> proportion! ;)

I didn't say I want it in the way Java does it (:-)) If exception contracts
will be adopted in Ada, I assure you, they will be made in a reasonable
Ada-way. For example, the contract or its parts will be inheritable.

> (I hated that feature already in C++ and Java and I'm glad it doesn't
> exist in Ada) ;)
> 
> For example, to show you why it's wrong: At my previous employer,
> there were lots of rather inexperienced programmers working on big Java
> projects. They would throw exceptions and not declare them properly,
> catch them properly and/or omit them from the method contract
> declarations. The result was that there were a lot of bugs related
> to exception handling.

This is statically checkable, so I presume that Ada 2100 would simply spit
an error message.

> Ada really simplifies exceptions a lot. And in the worst case, the
> program simply exits. (better than awkward handling and unpredictable
> behaviour)

... and your heart pacemaker reboots ...

> So having exception contracts for subprograms don't really eliminate
> the problems (programmers) in front of the computer! ;)

Yes, but DbC allows to manage the problems in a better way.

> Enumerations for exceptions might also be a bad idea. Imagine if
> someone puts an exception in the middle of some range that wasn't
> intended to be there, and *poof*, your good concept goes overboard.

No. Ranges in my view should serve the purpose of defining a class of
exceptions. IIF all exceptions has to be of same type, you need ranges for
things like:

exception
   when IO_Faults'Range =>
      -- try to recover here
   when others =>
      -- Clean up

Alternatively one could switch to C++ approach, though deriving all
exceptions from the same base. That has a great disadvange that the size of
an exception object would become unpredictable. This is not what I would
like to see in a real-time embedded system.

>> But again, there are problems. We need tasks and protected objects be
>> tagged types, separate bodies for accept statements, protected actions on
>> multiple protected arguments, rendezvous with multiple tasks... (I have a
>> large list)
> 
> I solved the accept-thing in my SYSSVC package by calling procedures in
> the accept handlers. :)
> 
> Perhaps some of the things that you wanted will go into the new Ada
> standard. In the meantime, I guess we have to do without them. ;)
> 
> And remember: There's always another way to do it! ;)

Work-around is the worst possible thing for an interface.

> Ada 95 provides me with programming conveniences I've never dreamt of
> before. It's like cotton candy to me! :)
> 
> (of course, as a C++ programmer, in the beginning I've cursed at some of
> Ada's peculiarities, but now I like them! ;) )

I learned Ada (83) before C and C++, so I never liked the latter. As for
peculiarities, most of them have a rationale. That's the difference between
Ada and C++. You need to fall in love with C++, blindly, because to like it
rationally, is impossible! (:-))

> Hah, you just need to "downgrade" your design a bit and make it simpler,
> not as fancy as you would with C++, and boom you get along well with Ada.
> :)

In fact, it is the opposite. Ada's approach to OO is much more advanced and
consistent than C++'s one. So one need to downgrade switching to C++.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de