"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote: > > snooze(5) is not equivalent to Java yield(), since at least > > according > > to the specification it is supposed to wait at least 5 us. I'm not > > sure > > about the timer granularity -- in practice it may indeed not wait > > at > > all (besides being rescheduled), or wait at least a longer > > interval. > Axel and I have talked about that. 5us is a very low value! It > could've > just been "1"! The purpose is to be greater than 0, and not to big! > For any > value >0 the thread is rescheduled and it will wait until the time > passes, > but if the value is extremely low(like "5"), the thread will NEVER > wait. > When its turn comes, the thread will execute because it is certain > that 5us > have passed since it has been rescheduled! In OpenBeOS there are some problems using the snooze(5) as yield() replacement: - it's not as cheap as a yield() could be, since you start a timer to wait on the semaphore, etc. - OpenBeOS boosts the priority of the waiting threads when their semaphore was released - now this is not really what you want with snooze(5), since that just sits on a semaphore; perhaps waiting on that semaphore shouldn't cause the priority boost. - it's always more expensive than waiting on the right semaphore directly, the thread has to be scheduled on and off, probably without doing anything at all > > Directly waiting on the port on the other hand will allow the > > thread to > > return immediatly, when a new message arrives. In case a new > > message > > arrived since the last port_count() (mind you, the thread could > > have > > been preempted inbetween) it may even not need to be rescheduled. > Hmm... not a good idea! I've told you, another message may have > been > arrived at the 2nd port! Actually, this is a good idea - but it depends on the context. Of course, this is especially a good idea if the other port could live with a latency brought in by polling on the main port. Even if you do a read_port_etc(..., B_RELATIVE_TIMEOUT, 5) on the main port, it will react better than doing a snooze() at this point. But I would choose a timeout as high as possible (without letting the user notice any lag, of course). Adios... Axel.