Re: Inheritance and Concurrency

Re: Inheritance and Concurrency

[David Weller]

In article <3lbp76$eti@news.cc.utah.edu>,
Shawn Willden <swillden@fcom.cc.utah.edu> wrote:
>David Weller (dweller@Starbase.NeoSoft.COM) wrote:
>: In article <D5wH8G.B9x@world.std.com>,
>: Bruce G Wilson <bgw@world.std.com> wrote:
>: >	There's a great article on the state of concurrent programming in C++
>: >in the January 1994 issue of the "C++ Report"; it's entitled "Concurrency
>: >Support for C++: An Overview" by Eshrat Arjomandi, William O'Farrell, and
>: >Ivan Kalas.  It mentions the "inheritance anomaly" problem in passing, and
>: 		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>: I'm not so sure it qualifies as a "great article" then :-)  THe
>: inheritance issue is a BIG problem.  It's very hard to solve, but is
>: very real.
>
>: There is also the school of thought that concurrency and inheritance
>: should _never_ be combined.  
>
>Excuse me if I'm missing something obvious, but could someone explain
>precisely what the problem is?  I've never worked in an environment
>where it was an issue, but I'm about to take over a large project
>(currently written in C) that uses concurrency extensively, and it
>appears to me that there are a number of pieces that are begging
>for inheritance, so I want to understand how the two could conflict.
>

Hmm, there's a few papers on this.  I'm sure Ciaran's paper will
discuss it most thoroughly.  There's also a discussion about it in
the paper I Co-authored, "Integrating Inheritance and Synchonization
in Ada9X" in Tri-Ada '93.  However, there's a better discussion in
Colin Atkinson's book, "object-Oriented Reuse, Concurrency, and
Distribution".

At the risk of being overly simplistic, consider this:  A bounded
Queue base class establishes a set of member functions, each with
their own synchronization locks.  Inheriting from this is fine,
provided you want those same synchronization controls.
Unfortunately, you were looking for something "a little different".
You could redefine the member functions (I hope they were declared
virtual :-), but you'd have to do that for _every_ derivation.  YOu
could leave them as abstract, but then you'd have to implement every
invocation yourself.  Basically, the power of inheritance (which
comes from reducing the code you must write) is nullified.  Even
worse, you could create a potential deadlock situation where a user
has intermixed similar classes that exhibit different concurrency
controls.  Writing piles of concurrent software with semaphores all
over the place is not fun to debug (trust me :-).  

Hmm, looking back at my previous paragraph, I fear I may do more harm
than good.  Still, I have a few other references I can dig up later.
Steven Goldsack wrote some papers long ago on behavioural inheritance
(Dr. Goldsack was Dr. Atkinson's advisor at Imperial College in
London).  All my research stuff on that is at home, perhaps another
net.person can help.


-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)