RE: [boost] boost::thread try_mutex, Win32 performance enhancemen t suggestion...

From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-04-12 13:30:16

Unfortunately, TryEnterCriticalSection isn't available on Windows 95/98/Me.

I definitely agree with you that it's a useful optimization for Windows
NT/2000/XP, but I don't think the focus has been on optimization on
sub-variants of Windows, (yet)...

Regards,
Dave

> -----Original Message-----
> From: Robert Saccone [mailto:rsaccone_at_[hidden]]
> Sent: Friday, April 12, 2002 12:03 PM
> To: boost_at_[hidden]
> Subject: [boost] boost::thread try_mutex, Win32 performance 
> enhancement
> suggestion...
> 
> 
> Sent this before but in html format by mistake.
> 
> -----Original Message-----
> From: Robert Saccone [mailto:rsaccone_at_[hidden]] 
> Sent: Friday, April 12, 2002 10:19 AM
> To: 'boost_at_[hidden]'
> Subject: boost::thread try_mutex, Win32 performance enhancement
> suggestion...
> 
> Two Suggestions:
> 
> I was looking over the implementation of the try_mutex class 
> and noticed
> that internally it uses a Win32 Mutex and does a WaitForSingleObject
> with a timeout of 0 in the do_trylock method.  The same thing can be
> achieved by using a CriticalSection and the 
> TryEnterCriticalSection API
> which is light weight compared to using a Mutex with a
> WaitForSingleObject call.  
> 
> TryEnterCriticalSection works as follows:
> 
> If there is no contention on the lock, the lock will be 
> acquired in user
> mode by using a few lock prefixed assembly instructions. 
> 
> If there is contention on the lock the TryEnterCriticalSection will
> return immediately.  
> 
> The EnterCriticalSection API works similarly with the exception that
> when there is contention on the lock it will follow the same code path
> as the WaitForSingleObject call and not return until the lock is
> acquired.  
> 
>  WaitForSingleObject is heavy weight in that the work is 
> always done in
> kernel mode with a much longer code path.  Since 
> TryEnterCriticalSection
> is only available on WinNT 4.0, Win 2K, and XP a possible a way to
> implement this is to restructure try_mutex to use the pimpl idiom and
> check the platform at the time of construction of the object.  The
> results of the platform check can be cached to speed construction of
> future try_mutex objects.
> 
> Also, I found that it is more efficient to use 
> WaitForSingleObjectEx and
> WaitForMultipleObjectsEx over the non-Ex versions.  Tracing in the
> debugger reveals that the non-Ex versions call the Ex 
> versions with the
> Alertable parameter set to FALSE.  You'll avoid the overhead 
> of an extra
> function call by using the Ex versions directly.
> 
> Regards,
> Robert Saccone
> rsaccone_at_[hidden]
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>