[Vm-dev] Why isn't signalSemaphoreWithIndex() thread-safe?

Eliot Miranda eliot.miranda at gmail.com
Mon Sep 21 21:51:13 UTC 2009


Hi John,

On Mon, Sep 21, 2009 at 1:26 PM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:

>
> Er, did we reach a consensus about what to do?
>
> My problem is determining what is best based on some the code concepts
> given (which people pointed out flaws in, or confusion about).
> and the premise they work all the same on different hardware platforms
> intel, powerpc, arm, which I'm not sure about.
>
> Perhaps a more heavy weight, platform dependent solution using the generic
> acceptable locking logic is required.
>

No, no, no, no. no :)  I'm currently implementing the scheme for testing
here at Qwaq.  So hang on for a day and I'll provide code to start from if
our testing is positive.


> Er like
> acquireTheHostPlatformIndexedSemaphoreLock()
> {Do what ever is required to remember the semaphore index so that
> checkForInterrupts can find it, a queue perhaps?
> releaseTheHostPlatformIndexSemaphoreLock()
>
> I'd keep in mind
>
> (a) How many times do we execute the signalExternalSemaphore logic per
> seconds, and
> (b) if someone want to do  this a million times a second I think they can
> do their own "exotic" solution via overriding
> acquireTheHostPlatformIndexedSemaphoreLock &
> releaseTheHostPlatformIndexSemaphoreLock
> (c) keep it simple so I don't have to worry how it works on powerpc, intel,
> and arm.
>
>
> acquireTheHostPlatformIndexedSemaphoreLock/releaseTheHostPlatformIndexSemaphoreLock
> Obviously I'd just throw myself on the evil pthread solution.
>
>
> Would we do a linked list, or queue for the semaphores, versus that fixed
> size list? A size I picked based on exploring network interrupt value rates
> on a mind numbling 200Mhz powerpc machine?
>
>
> On 2009-09-20, at 7:00 PM, Igor Stasenko wrote:
>
>>
>>
> --
>
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:
>  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090921/60fe38f6/attachment.htm


More information about the Vm-dev mailing list