[squeak-dev] Re: Socket clock rollover issues
John M McIntosh
johnmci at smalltalkconsulting.com
Wed Apr 29 02:03:59 UTC 2009
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
=
=
=
========================================================================
More information about the Squeak-dev
mailing list
|