[M3devel] Why do we not check stackbase=NIL anymore in ProcessOther?
Jay K
jay.krell at cornell.edu
Fri Dec 11 16:02:16 CET 2009
I know what I was thinking, but it doesn't make sense any more.
I could have sworn I saw a race where the value changed between
the check and the subsequent read/use.
That makes sense, in that I don't change the value under a lock.
But it doesn't make sense, in that the changer should be suspended.
The check is done shortly after in the C code though.
There is just one read, and the purported race is gone.
It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does.
I looked at, but I didn't follow through as to the other uses of the state it changes.
- Jay
> Date: Fri, 11 Dec 2009 15:57:50 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 09/12/11 15:57:50
>
> Modified files:
> cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3
>
> Log message:
> Tidy a little.
> Why do we not check stackbase=NIL anymore in ProcessOther?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091211/9141c2b2/attachment-0001.html>
More information about the M3devel
mailing list