On Friday, June 01, 2007 Ian Frosst wrote: > 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.
That may work for you, but has the possible drawback of starving a thread... Windows doesn't guarantee that the woken thread is the one at the head of the "queue." See, e.g., http://blogs.msdn.com/oldnewthing/archive/2006/03/13/550402.aspx So, I never use PulseEvent or Automatic Reset events. Of course, if you expect there to be intervals when there are no waiting threads, and you can afford to wait for that interval for a synchronization point, and you don't care the order in which the inserts are performed, the Automatic Reset event might work. e > 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 -- Doug Currie Londonderry, NH, USA ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
