Boost logo

Boost :

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-02-07 09:40:13

Hash: SHA1

Jon Jagger wrote:
>I think there's a small buglet in the assignment for linked_ptr.
>It reads....
> this_type & operator = (this_type & other) { ...
>shouldn't it be
> this_type & operator = (const this_type & other) { ...

Yup, good catch. Changed.

Everything below this is platform specific & about windows

Greg Colvin wrote:
>This seems pretty expensive. Eliminating the unnecessary try/catch
>in sync_lock::lock() helps some:

It is not entirely unnecessary, since the documentation for the
InitializeCriticalSection API function states that "In low memory
situations, InitializeCriticalSection can raise a STATUS_NO_MEMORY
You are partly correct, in that it is unnecessary to put the
try-catch around the entire function, so I moved the try-catch to
protect only that call to InitializeCriticalSection. This should
limit the exception handling overhead to the initialization only, not
any subsequent usage.

>It may be heresy, but a spin lock gives better results when there is
>no contention,
> and the critical section here is rather short

A while back, I put together a high level spinlock using the
InterlockedIncrement & InterlockedDecrement calls. I compared this
to CriticalSection and they were basically identical. It may be
possible to get some better performance by using asm. I do not know
assembly very well.

Unless it presents some significant (50% or so) performance
improvements, I'd argue against putting asm into boost code. It
would make the code less understandable to assembly impaired
individuals like myself. I'd think twice before using library source
code that I couldn't maintain.

I think the Win32 critical section mechanism basically uses
spinlocks. The struct definition (in winnt.h) has a DWORD member
called SpinCount.

Version: PGPfreeware 6.5.2 for non-commercial use <>


Boost list run by bdawes at, gregod at, cpdaniel at, john at