Thread-safety of TemplateRegistry
Max Dmitrichenko
I'm getting a strange problem. My 64-bit multithreaded application
accidentally segfaults or aborts in a non-reproductive manner. Some
things that I've noted:
1) Single threaded application doesn't crash. At least it works 30
times longer.
2) Crash happens after several minutes (approx. 15) for two threads
3) Stack examination shows that crash almost always happens in the
methods of FieldIdentity class or in heap managment functions (malloc,
free etc.)
After looking into the QuickFAST's code I noticed that FieldIdentity
uses boost::intrusive_ptr concept to track references. But this
implementation isn't thread-safe because C++ doesn't guarranty the
atomicity of increment/decrement operations, and the code itself
doesn't use atomic primitives like decrement_and_test. I suppose that
during message decoding field identities (actually pointers) are
copied from template registry into a FieldSet object, so this action
changes the reference count. After the message is destroyed the
reference count decrements. Here happens a race condition - sometimes
increments are overwritten by decrements and soon or a later an object
is free'ed while it used by another thread or a double free occuries.
May be this deppends on running architecture (32/64-bits) or
optimization keys enabled.
Can someone acknowledge or disaprove my hypothesis?
If I'm right with it, is there any other objects in library which
suffer from the same problem? I guess it'll be enough for each thread
to have its own copy of TemplateRegistry to overcome the problem?
--
WBR,
Max
Dale Wilson
Reply in-line below.
The entire Decoder is intentionally NOT thread safe. There must be only
one thread in any instance of the Decoder (or Encoder) at any time.
Using the communication support that is part of QuickFAST this is enforced.
Ideally FieldIdentity should be allocated at startup and only released
during final shutdown.
The intrusive pointer is a relic from an earlier version of QuickFAST
which did not use this approach.
Dale
>
> --
> WBR,
> Max
>
--
Dale Wilson
Principal Software Engineer
Object Computing, Inc.
Max Dmitrichenko
2012/1/26 Dale Wilson <wil...@ociweb.com>:
> The entire Decoder is intentionally NOT thread safe. There must be only one
> thread in any instance of the Decoder (or Encoder) at any time.
> Using the communication support that is part of QuickFAST this is enforced.
In my case I have only one thread per decoder. But a TemplateRegistry
instance was shared among several decoders.
Please remove (or edit appropriately) this comment from
XMLTemplateParser description:
///
/// Multithreading Note:
/// This class was designed under the assumption that it would
be run once during
/// initialization. There are no guarantees that template
parsing is thread-safe.
/// The resulting template repository, however, can be safely
shared between
/// threads.
--
Max