debugging critical section
Ross Boylan
RossBoylan at stanfordalumni.org
Wed Mar 24 07:25:55 UTC 2004
I'm running into various problems debugging a critical section of
code. Is there a way around them? Or should it just work, and I
should look elsewhere for the problem?
First attempt: I used Monitor>>critical: and had the halt outside the
call. However, even though I tried to use send in the debugger to
step into the block, it took me through it. I have a foggy
recollection of seeing this behavior before.
Second attempt: self halt inside the block. With this, the debugger
comes up, but when I try to enter the debugger the best I can do is
getting the debugger to come up. I'm never able to select a stack
frame; my system uses lots of CPU and then the squeak image becomes
totally unresponsive (though CPU is 0). Even alt-., though it brings
up a notification window, doesn't let me regain control.
Notes/Caveats:
_____________
Squeak 3.2, last update 4956, i.e., not at all recent.
Running under Debian GNU/Linux.
Image is pushing 70Mg, and I frequently have to wait extended periods
(15 seconds) while it thinks after I do something. (Could just be
that I'm swapping: 128Mg physical RAM).
If I had more time, I'd deal with some of those problems, but for now
I'm trying to fix a relatively limited bug.
Monitor, as I recall, was a little something I imported. I've
attached it, just in case. It lets the owning process in repeatedly,
but prevents other processes from acting. Hmm, I wonder if using the
debugger implies I've changed active processes, and so Monitor is
blocking me...
P.S. As I have not been following developments closely for quite a
while, I had a browse to try to catch up. But I could not find a
clean summary of the changes in the different versions of squeak since
3.2. Any pointers?
-------------- next part --------------
'From Squeak3.2 of 29 April 2002 [latest update: #4956] on 23 March 2004 at 11:21:06 pm'!
Object subclass: #Monitor
instanceVariableNames: 'accessLock waitSemaphore owner waiting '
classVariableNames: ''
poolDictionaries: ''
category: 'Kernel-Processes'!
!Monitor commentStamp: '<historical>' prior: 0!
A monitor is - like a semaphore - used to synchronize access. Contrary to semaphores, monitors can be entered multiple times by the same process.!
!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:05'!
critical: aBlock
"Evaluate the given block, excluding accesses from other processes."
self enter ifTrue:[^aBlock value].
^[aBlock value] ensure:[self leave].! !
!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:05'!
critical: aBlock ifOwned: ownerBlock
"Evaluate aBlock if the receiver is not owned by the current process. Evaluate ownerBlock if it is already owned by the current process."
self enter ifTrue:[^ownerBlock value].
^[aBlock value] ensure:[self leave].! !
!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:06'!
enter
"Enter the monitor. Return true if the receiver was owned by the active process, false otherwise."
| doWait process wasOwned |
[doWait _ false.
accessLock critical:[
process _ Processor activeProcess.
wasOwned _ process == owner.
owner
ifNil:[owner _ process]
ifNotNil:[doWait _ wasOwned not].
waiting _ waiting + 1.
].
doWait] whileTrue:[waitSemaphore wait].
^wasOwned! !
!Monitor methodsFor: 'control' stamp: 'ar 2/3/2002 18:01'!
leave
"Leave the monitor"
| process wasOwned |
accessLock critical:[
process _ Processor activeProcess.
wasOwned _ owner == process.
wasOwned ifTrue:[
owner _ nil.
waiting > 0 ifTrue:[
waiting _ waiting - 1.
waitSemaphore signal]]].
wasOwned ifFalse:[^self error:'Process did not own monitor']! !
!Monitor methodsFor: 'initialize' stamp: 'ar 2/3/2002 17:56'!
initialize
accessLock _ Semaphore forMutualExclusion.
waitSemaphore _ Semaphore new.
owner _ nil.
waiting _ 0.! !
"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
Monitor class
instanceVariableNames: ''!
!Monitor class methodsFor: 'instance creation' stamp: 'ar 2/3/2002 18:03'!
new
^super new initialize! !
More information about the Squeak-dev
mailing list
|