XPost: alt.os.development   
   From: mailbox@dmitry-kazakov.de   
      
   On Sun, 19 Feb 2006 23:34:02 +0300, Maxim S. Shatskih wrote:   
      
   >>> Why not use functions for threads, rendezvous and mutexes? Why bother the   
   >>> language itself with such?   
   >>   
   >> Firstly, it is too low-level. Secondly, functional decomposition does not   
   >> well capture the semantics of concurrency. Thirdly, OSes always were better   
   >> than that.   
   >   
   > Disadvantages: lack of flexibility, hiding of subtle details, complete "black   
   > box" known to the compiler vendor only, unportable (the underlying mechanics   
   > cannot be easily ported since this is a trade secret of the compiler vendor,   
   > remember the story of RtlUnwind call in Windows?), cannot be extended and/or   
   > updated, major issues in creating a debugger, and so on.   
      
   Functional decomposition does not address portability. Portability is about   
   the semantics of the language constructs. When I write int X I tell very   
   little about X. That's non-portable. When I do type X is range -100..100,   
   it becomes portable.   
      
   As for secrets, I don't care about how a vendor implement the *standard*. I   
   recommend our customers Ada for this reason. There is an ISO standard,   
   there exists certification procedure. When I take a validated compiler, I   
   know very well what it does. In the places where the standard allows some   
   implementation freedom, it also requires the vendor to document the   
   implementation.   
      
   > Functional decompositin matches the semantics of concurrency very well. What   
   is   
   > wrong in EnterCriticalSection/LeaveCriticalSection calls and CRITICAL_SECTION   
   > object?   
      
   Safety. You need a helper object to ensure freeing the resource [in the   
   destructor.] Though this still wouldn't prevent deadlocks. Because just two   
   mutexes can create a deadlock.   
      
   Mutex is too low-level. Problems are: deadlocks and priority inversion. In   
   general, mutexes aren't composable. That means: put together two safe,   
   tested pieces of code, and you won't be able to say anything useful about   
   the combination. With functional-only decomposition it becomes a disaster,   
   because the callee does not know mutexes held along the path. According to   
   the paradigm it shall *not* know it. The contract of the callee is it   
   formal parameter list. If the call stack, the history etc should also   
   determine what and how it does, then it no functional decomposition   
   anymore!   
      
   The problem isn't to be able to write something, after all, almost every   
   language is Turing-complete. The problem is to manage complexity.   
   Functional decomposition alone is too weak.   
      
   > Supporting any complex stuff at language level is usually evil. That's why C   
   > and C++ is so popular. C++ only does exceptions and RTTI at language level,   
   and   
   > is heavily criticized for the latter (#define-based RTTI is better).   
      
   C++ is a bad language, especially because of its types system. The core   
   problem that there is no distinction between types and classes. As the   
   result:   
      
   1. Small value objects cannot have classes (int)   
   2. Multiple dispatch cannot be implemented   
   3. Multiple inheritance requires lots of vtab pointers   
   4. Construction model is unsound (no dispatch in c/dtors)   
      
   >> about safe, distributed, preemptive, portable, scalable, real-time etc   
   >> system, I see no way to handle it without addressing these issues on the   
   >> language level.   
   >   
   > Linux is safe, distributed, portable, scalable, real-time (with extensions)   
   > system,   
      
   Where is a smiley? That's a joke, wasn't it?   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)