Re: [Sc-devel] [bug] possible race condition in server between SC_AudioDriver::RunThread()and ProcessOSCPacket()

["James McCartney" <asynth@xxxxxxxxx>]

On Jan 8, 2008 10:30 PM, Ross Bencina <rossb-lists@xxxxxxxxxxxxxx> wrote:
> Hi Guys
>
> Sorry for the possible repost, I'm not sure whether this got through last
> week...
>
> Look what I found...


> Assuming others agree there is a problem, I think there are a few possible
> solutions:
>
> #1, wrap the call to mFromEngine.Perform(); in SC_AudioDriver::RunThread()
> with calls to lock/unlock:
> mWorld->mDriverLock->Lock();
> mFromEngine.Perform();
> mWorld->mDriverLock->Unlock();
>
> #2, move the locking into SendMsgToEngine. This would mean one lock/unlock
> for every SC_SequencedCommand, even if there were multiple in one NRT cycle,
> however this would fix potential bugs when SendMsgToRT is called via
> InterfaceTable.
>
> #3 get rid of mDriverLock and use mNRTLock in ProcessOSCPacket() -- I have
> no idea what other side effects this would have.
>
> #4 use a separate FIFO for sending OSC packets to the RT Engine. This would
> mean zero interference with the scheduling of the NRT thread, and wouldn't
> add much additional code (although it would lead to allocating another FIFO
> buffer)...
>
> I think the last option (option #4) is probably the best. Thoughts?

either 1 or 4.
1 is the quickest fix.
4 is better in the long run.

thanks for finding this.

-- 
--- james mccartney