|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-06-04 08:19:06
From: "Alexander Terekhov" <terekhov_at_[hidden]>
To: <pdimov_at_[hidden]>
boost-owner_at_[hidden] schrieb am 04.06.02:
> You are not allowed to post to this mailing list, and your message has
> been automatically rejected. If you think that your messages are
> being rejected in error, contact the mailing list owner at
> boost-owner_at_lists.boost.org.
>
> <hr>
>
> Peter Dimov wrote:
> [...]
> > But the other side of the coin is that the 'proper' methods take more
memory
> > and cost performance, the spinlock 'hacks' do work (most of the time
;-) )
> > and a generic pthread_mutex/CRITICAL_SECTION version inevitably leads to
> > feedback that it's grossly inefficient. Which sometimes it is. In some
> > scenarios a CRITICAL_SECTION is orders of magnitude slower (I've
misplaced
> > the napkin with the exact results of my scientific experiments, but it
was a
> > dual CPU/win2k.)
> >
> > What should we do?
>
> Well, I guess...
>
> Bombard-to-death ;-) TOG/Austin Group reflector[1] (MS
> IS the 'silver' TOG member[2] as well ;-)) with zillions
> of messages requesting new opaque type pthread_refcount_t
> (or something like that) plus 'count'-calls/macros...
> with perhaps even more 'optimized' [for immutable objects
> only] counterparts -- operations at least; not sure w.r.t
> the separate extra opaque type -- could be the same one,
> perhaps.
Well, to make the current implementation mutex-free I need a "test and
conditionally increment" atomic op that's generally unavailable (memory
visibility issues aside ;-) .) A "normal" mutex (specification-wise) that is
optimized for this particular use pattern is fine, as long as its
performance/footprint is OK.
A compromise would be to keep the broken spinlock on Windows, and use
pthreads on everything else. Would that be acceptable to shared_ptr users?
> In the meantime, if performance/footprint is so critical
> (which I doubt somewhat, frankly)
So do I, but users tend to be picky about it. ;-)
> 'fake' it in the 'asm'
> for each platform/compiler/whatever.. Ugly, yes, but I
> really don't see any other alternative. :-(
>
> regards,
> alexander.
>
> [1] http://www.opengroup.org/austin
> [2] http://www.opengroup.org/overview/members/membership_list.htm
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk