Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Subject: RE: 1.3.4? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 24 Sep 2001 15:51:23 +1000 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1.3.4? Thread-Index: AcFEu+H9VHUXsfzDRBSgMpwBL1Y6SwAABDHg From: "Robert Collins" To: "Matt" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id BAA12253 > -----Original Message----- > From: Matt [mailto:matt AT use DOT net] > MSDN says MsgWaitForMultipleObjects can be used instead of > SignalObjectAndWait in certain circumstances. While it doesn't support > Critical Sections, it is supported on win9x. Thanks, however I already looked at this and it's not appropriate. The problem is not windows 95 support - it's a race between exiting the protected area and waiting on the event object. SignalObjectAndWait solves that by being atomic with respect to _both_ the ibject to signal and object to wait on. MsgWaitFor... does not signal an object, so the race still exists. The NT function does not support Critical sections either, which is why this race now exists for NT as well as for 95 (which doesn't have the SignalObjectAndWait function at all). Mutex's are much slower than Critical sections, so this _is_ a trade off. Basically, AFAICT, MS were still learning how to program preemptively on 95. Rob