Correction: Deriving (& dying) from Semaphore
jchludzinski at grci.com
jchludzinski at grci.com
Tue Apr 25 17:58:55 UTC 2000
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
>>
>>
>>
>
>
More information about the Squeak-dev
mailing list
|