Re: Why I believe in static analysis

From: Steven E. Harris (seharris_at_raytheon.com)
Date: 11/21/03 

Date: Fri, 21 Nov 2003 11:19:08 -0800

Peter Seibel <peter@javamonkey.com> writes:

> I'm not sure I'd give up on the reliable core concept that easy--if
> you've defined a core that you belive covers all the needs of the
> folks who are supposed to be using, it ought to be fairly
> straightforwerd (either by automation or simply by good practice) to
> make sure that no one is using the primitives outside the core.

We have a similar situation here, albeit with a large embedded C++
project. Our "reliable core" is a framework that coordinates several
threads handling network I/O and timers, synchronizing these services
so that the application riding atop can be written in single-threaded,
event-driven fashion. The application code is never called from more
than one "framework thread" at a time; the application can't tell that
there is more than one thread running underneath the main framework
callback loop.

With that in hand, you can have tons of novice-to-intermediate
programmers writing simple application code without having to be
well-versed in concurrent programming. We have these programmers, and
it's almost working out, if only the applications were that simple.

It turns out that most of the applications -- all supposedly
event-driven -- have requirements that prevent them from working well
in (apparently) single-threaded fashion. No callback function can take
too long, for it's holding up the main event loop. So long-running
computations must be haphazardly chopped up into pieces, dispatched by
timers and state machines. The framework can't block on arbitrary
events, so an application-level network connection can't be connected
in and dispatched by the main event loop.¹ Sometimes this manual
time-slicing, limited to non-blocking operations, is more cumbersome
than just dedicating a worker thread to a given computation and
confronting the synchronization and data sharing details.

Even though the framework is supposed to free the applications from
concurrency constructs, many of the applications can't be written well
without creating extra threads, so we have our under-trained or
inexperienced programmers doing one of two things: writing clumsy,
manually time-sliced, faked-up concurrent programs within the
single-threaded confines of the framework, or stepping outside and
making dangerous concurrency mistakes above the "safe" framework.

We can't win enforcing use of a solution simpler than the actual
problem it aspires to solve.

Footnotes:
¹ The ACE library's Reactor facility solves these problems. We use it
  in places at the application layer because the framework does not
  incorporate application-supplied handles for demultiplexing. 

-- 
Steven E. Harris        :: seharris@raytheon.com
Raytheon                :: http://www.raytheon.com

Relevant Pages

  • Re: Why I believe in static analysis
    ... > underneath the main framework callback loop. ... > programmers writing simple application code without having to be ... > Even though the framework is supposed to free the applications from ... do something outside my basic conceptual framework I know I'm about to ...
    (comp.lang.lisp)
  • Re: About speed
    ... There's two things in the sample: the .NET framework libraries, ... A lot of people thought that one day all business applications would be ... with only lower level coding requiring the power of C++. ... programmers, but by business people. ...
    (borland.public.delphi.non-technical)
  • Re: Consolidating java objects
    ... I would try an approach where you try to elicit the real framework information from the programmers, perhaps by a couple of meetings or coffee break chatting, or something. ... way to compare all of these objects to see what is similar. ... different packages it is unbelievable. ...
    (comp.lang.java.programmer)
  • Re: What Borland should stop wasting their time on
    ... The framework has a lot of promise, but I think Microsoft was far too ambitious releasing far too many assemblies much too quickly. ... As a result design suffered, but to provide backward compatibility, Microsoft could not simply redesign the whole library and deprecate the old one. ... C/C++ programmers are on a different league as .NET. ... This concept is pioneered by Delphi and Java. ...
    (borland.public.delphi.non-technical)
  • Re: Competition is not ALWAYS good
    ... you see web framework as a must-use product. ... their applications in bare PHP -- and be quite successful with this. ... SB> is a religion then yes I am religious. ... so for people who actually want application up and running portability has ...
    (comp.lang.lisp)