For Windows, this is not the case with Automatic Reset events. The system guarantees that only one thread waiting on the event is woken up (it keeps a queue): the others happily keep sleeping until the next setting of the event.
On 6/1/07, Doug Currie <[EMAIL PROTECTED]> wrote:
On Friday, June 01, 2007 Ian Frosst wrote: > On the topic of a more efficient busy handler, one approach I considered was > to implement an event which was signalled when a database unlock occurred. > That way, the busy handler could just wait on the event (which is an > efficient wait state), and be guaranteed of a wake up when the lock is > released (the event would be signalled at this time.) However, I wasn't at > the time familiar enough with SQLite's innards to implement such a beast. > Can anyone see any pitfalls to such an approach? The problems occur when multiple threads are waiting on the event; they all wake up and compete for the resource again. For better solutions, see: http://world.std.com/~jmhart/batons.htm e -- Doug Currie Londonderry, NH, USA ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
