In actuality, I modified the Semaphore class itself adding a
#critical2 method (and'holder' instance var.), which checked
for 'holder == Processor activeProcess'.

The hypothetical method #critical:processRef: (mentioned below)
was an attempt to explain my intent - I don't think it helped.

I imagine that modifying a primitive class (Semaphore) is
the ultimate Smalltalk faux pas?  It worked though!


---John


PS. Finally, I meant to write: I believe JWARS is currently
the largest Smalltalk project extant?



4/25/2000 9:14:02 PM, jchludzinski at grci.com wrote:

>It doesn't appear to be a problem for VW and evidently,
>nor for VA.  At JWARS, a large DoD wargaming project using VA,
>one of the engineers tells me that they have 5
>subclasses of Semaphore.  (I believe JWARS is currently the
>largest ST extant?)
>
>I would like to extend (subclass) Semaphore to add a 'holder'
>instance variable so that the #critical: method 
>(now #critical:processRef:) allows me to check if the process
>in the critical block (the 'holder') is trying to execute
>another critical block using the same Semaphore - thereby hanging.
>If so, the #critical:processRef: method becomes a no-op.
>(i.e. holder == processRef).
>
>
>--John
>
>
>
>4/25/2000 5:14:32 PM, "Lex Spoon" <lex at cc.gatech.edu> wrote:
>
>>jchludzinski at grci.com wrote:
>>> 
>>> I attempted to derive a class from Semaphore but died sending the message #forMutualExclusion (to the derived class).  The error occurs when the derived method #signal sends "self primitiveFailed".  Why?
>>> 
>>
>>The primitive for Semaphore>>signal in Squeak looks like this:
>>
>>	primitiveSignal
>>
>>		| sema |
>>		sema _ self stackTop.  "rcvr"
>>		self assertClassOf: sema is: (self splObj: ClassSemaphore).
>>		successFlag ifTrue: [ self synchronousSignal: sema ].
>>
>>
>>Note the second-to-last line which explicitly checks the class of the
>>receiver--the receiver is expected to be *exactly* class Semaphore, and
>>not a subclass.
>>
>>I guess it would be nice to be able to subclass Semaphore.  Perhaps the
>>VM should check whether the receiver is a subclass of Semaphore, and
>>allow that as well.  It doesn't seem like *that* big a deal that such a
>>low level class can't be subclassed, but then again, it would make for
>>awesome bragging rights for Squeak.  :)
>>
>>
>>-Lex
>>
>>
>>
>
>