[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