On 28-Apr-09, at 6:46 PM, Andreas Raab wrote:

> John M McIntosh wrote:
>> Er, so given we don't have a thread safe signalSemaphoreWithIndex  
>> code base (on purpose) I wonder how many signals per second are you  
>> doing and are you perhaps
>> overflowing the semaphoresUseBufferA/B table? Assuming you are  
>> saying you do the signalSemaphoreWithIndex() and you never see that  
>> over in the image?
>
> I cannot prove any of this because it's so unreliable but I don't  
> think that's the problem. An overflow like you are describing is  
> only possible if you overflow before the VM (not the image!) gets to  
> the next interrupt check. If that were the case (for example because  
> we're spending too much time in some primitive like BitBlt) I  
> believe we'd be seeing this problem more reliably than we do.

Ok well people are welcome then to look at the semaphoresUseBufferA/B  
logic (is there an off by one error there?) and consider the issues  
with multi-cpu machines and if there are any exposures to loosing a  
signal, versus overflowing the table. Frankly I wonder about the  
safety of foo->semaphoresUseBufferA


> Also, the Windows VM actually replaces signalSemaphoreWithIndex with  
> a version that *is* thread-safe in the proxy interface since this  
> used to be an issue in the past. It is still possible to overflow  
> the semaphores but not that you're competing between two threads  
> when signaling (i.e., overwriting entries because threads are  
> executing on different cores).

Er, maybe you could buy those window's boxes and accidently run linux  
or freebsd on them, and pretend they are windows machines, I mean if  
they are stuffed away in some ISP's rack/cage who would know what they  
run anyway?   However you have to prove you are not loosing interrupts  
from somewhere in the bowels of the windows socket code heh?

>
> Perhaps most importantly, the last place where I've seen this happen  
> was in a callback which means the signaling code was running from  
> the main thread. There is of course a possibility something  
> completely else goes wrong (random corruption of the semaphore index  
> for example) but I haven't had the time to investigate this - I was  
> more interested in finding a suitable workaround for the release ;-)

No doubt you then have to follow the trail from synchronousSignal()  
and confirm in your mind that it does reach the smalltalk object....
>
>
>
> Cheers,
>  - Andreas

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:   
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================