Re: Alexandrescu MC++D: SmallObjAllocator problem
* Ingolf Steinbach:
Hi,
Well hi, you surname-hijacker.
while reading section 4.8 ("Simple, Complicated, Yet Simple in the End")
of Andrei Alexandrescu's "Modern C++ Design" (13th printing), I had
difficulties to understand why it is sufficient to derive SmallObject
from ThreadingModel<SmallObject> in order to avoid problems with
multithreading.
In addition to deriving from ThreadingModel (which looks like CRTP
derivation), locking -- presumably provided by the ThreadingModel --
is introduced in the operator new() and operator delete() operations.
Similar locking would have to be introduced in member functions with
concurrency issues in classes derived from SmallObject.
Wouldn't it be necessary to include some sort of synchronization to
*MyAlloc* itself?
Not as long as all operations using MyAlloc have been properly modified
to provide mutual exclusion.
My understanding of the code as described in that
section is that all SmallObject instantiations (for different threading
models) use the same SmallObjAllocator instance. So, if we have
three different threading models providing
- locking mechanism A,
- locking mechanism B, and
- no locking at all
respectively, simultaneous creation of SmallObjects of different threading
models (for instance deeply buried in three different libraries) would
possibly lead to concurrent access to MyAlloc.
Yes. I'm not sure what Andrei's rationale was, but one advantage of
locking at the highest possible call level is that you can do a bunch of
efficient low-level calls within the same lock. But as you note, the
downside is that it doesn't provide an iron-clad guarantee: you can
circumvent it all simply by using high-level calls that don't lock.
Also, as far as I can see there isn't any place that bunches of
low-level calls are done.
Perhaps Andrei could comment on this.
In my opinion, there would
have to be one SmallObjAllocator instance per threading model which does
the locking within Allocate() and Deallocate() itself.
Well, you'll note on the bottom of page 91 that MyAlloc is defined as
typedef Singleton<SmallObjAllocator> MyAlloc;
(actually for some reason my eyes overlooked that definition in the
paper copy, unable to see it, but Adobe Acrobat found it readily enough
in the online PDF version of the book at <url:
http://www.source-bg.com/books/cpp/ADDISON_WESLEY___MODERN_C__.PDF>, and
perhaps Andrei could comment on whether that is a /legal/ copy?).
And all you need to do to have one SmallObjAllocator per threading model
is presumably to put that typedef in the SmallObject class and change it to
typedef Singleton<
SmallObjAllocator,
CreateStatic,
DefaultLifetime,
ThreadingModel<SmallObject>
> MyAlloc;
although I haven't tried this.
The old copy of Loki that I have includes, in SmallObject, the comment
// The typedef below would make things much simpler,
// but MWCW won't like it
// typedef SingletonHolder<MySmallObjAllocator/*, CreateStatic,
// DefaultLifetime, ThreadingModel*/> MyAllocator;
and instead uses
struct MySmallObjAllocator : public SmallObjAllocator
{
MySmallObjAllocator()
: SmallObjAllocator(chunkSize, maxSmallObjectSize)
{}
};
Am I missing something? (I have not yet read further in that book. I am
just trying to understand it reading from front to back.)
No, it seems you have a good point, but it's just a design issue.
Microsoft, if Microsoft had made Loki, would probably have documented
this issue as "This is by design". :-)
Hth.,
- Alf
%% The campaign to answer articles with no follow-ups so far.
%% Posted 12.05.2007 09:56 (my articles often linger in the queue since
%% I can't process my own articles, hence the datetime stamp).
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]