Re: [Alephmodular-devel] Detangling/de-Mac-ifying

[Woody Z. I. <woo...@ve...>]

You guys may or may not find any value in this document (and perhaps  
especially its accompanying diagram):
http://source.bungie.org/_enginedevelopment/reference/networking- 
input.html

Also a couple notes - I'm pretty sure that in Mac OS 9-land, VBL stuff  
(and other "interrupt" sort of routines, like network-packet-received)  
run to completion before pretty much any other code can run (certainly  
before "main loop" code can run).  On the other hand, note that the  
main code could be preempted at pretty much any time for interrupt  
tasks.  (IIRC.)  As I recall, I was careful to simulate this behavior  
in the SDL port of the threading stuff when I did IP ring.  Though I  
might have had to protect certain critical sections that didn't need  
protection before, since I couldn't guarantee that non-main threads  
would run their stuff to completion.  I honestly don't recall at this  
point.  IP star protocol was built from the ground up with the current  
context in mind, so it might use a somewhat different strategy for  
threading/locking.

The circular buffer/circular queue is a standard way of decoupling  
producers and consumers, and if implemented properly should not require  
any locking (part of its appeal).  That comparison you were worried  
about, if the buffer is implemented properly, should only ever return a  
"false negative" to the question "is there something to read?" - and  
that's no problem because the consumer will be back around to ask again  
soon.  (There's a similar check for queue full that has a similar  
rationale behind it.)  Try to reason it out if you want, or I'm sure  
you can find plenty of writeups out there describing it in more detail.

Good luck,

Woody


On Wednesday, May 18, 2005, at 02:12  AM, Chris Pickel wrote:

> On May 18, 2005, at 12:00 AM, Br'fin wrote:
>> Main Thread (Handles Mac Events) - Also handles updating the world  
>> and rendering the screen.
>> Input Thread (Runs as a VBL API thread) - Polls mouse location and  
>> keyboard state 30 times a second, updates input queues
>
> Hmm, I think I see how this is supposed to work. I read through what I  
> could find of thread use, and I find one thing somewhat curious: there  
> doesn't seem to be any concept of thread-safety in the code. mytm.h  
> defines two mutex routines, but they aren't used. It appears to me  
> that the assumption in the code is that only the input thread is  
> responsible for write_index and its contents, while only the main  
> thread is responsible for read_index and its contents.
>
> This might be a good assumption, but I'm not convinced that it's safe  
> to do; the input_controller function does a comparison between  
> read_index and write_index, and I was always taught you're not  
> supposed to do that without a mutex.