我在Solaris 10上的多线程C ++应用程序中获得了SIGSEGV内存争用。核心pstack的片段如下所示：
----------------- lwp# 4 / thread# 4 --------------------
ff14cc20 memcntl (e6400000, 653b8c0, 4, 0, 1, fffc00) + 8
001e4b38 msync__7MmapMgri (fb7ffd9c, 1, 0, ff1b9330, 1, ff1b3a20) + 84
001e4a8c rmMap__7MmapMgr (fb7ffd9c, fb7ffd9c, ff1b5900, 0, fc551200, 0) + 48
00159c08 dropRecs__12ReconInitMgr (fb7ffd78, 30b400, 506608, 0, fc551200, ff120400) + 1c
00159af8 _._12ReconInitMgr (fb7ffd78, 2, 176950, 7a8da0, b4, 1) + 1c
0015afec preprocessInitLegs__8CDRReconRCt6vector2Zt12basic_string3ZcZt18string_char_traits
1ZcZt24__default_alloc_template2b0i0Zt9allocator1Zt12basic_string3ZcZt18string_char_traits1
ZcZt24__default_alloc_template2b0i0 (508058, fb7ffe70, 506668, 218a88, 15, 508bb8) + 368
0015a95c compareLegsBySwitch1__8CDRReconi (508058, 15, ff1b5900, 0, fc551200, ff142a78) +
300
00161c3c comparatorConsumer__8CDRRecon (508058, 161ab4, 0, 0, fc551200, 1) + 188
0011c760 processForComp__FPv (508058, fb800000, 0, 0, 11c71c, 1) + 44
ff1494f0 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 5 / thread# 5 --------------------
ff14d1e4 _lwp_kill (6, 0, ff1b5090, ff12c928, ffffffff, 6) + 8
ff0c1bac abort (1e5bf8, 1, 2534f4, ee930, ff1b34d8, 0) + 110
001e5d38 corehandler__7CdrSigsi (b, 0, faffeb18, 1, 0, 0) + 140
ff14961c __sighndlr (b, 0, faffeb18, 1e5bf8, 0, 1) + c
ff13dce8 call_user_handler (b, 0, 4, 0, fc551a00, faffeb18) + 3b8
ff13ded0 sigacthandler (b, 0, faffeb18, 11, 0, 0) + 60
--- called from signal handler with signal 11 (SIGSEGV) ---
001307cc allocate__t24__default_alloc_template2b0i0Ui (20, 20, 30aad0, 1, 11, 0) + a4
0011e2cc __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b
0i0_3RepUiUi (10, 10, 0, 0, 0, 0) + 14
0011e30c create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template
2b0i0_3RepUi (a, a, 0, 0, 0, 0) + 24
0011e6d0 replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2
b0i0UiUiPCcUi (fafff608, 0, ffffffff, fafff6e0, a, 80808080) + 114
00134504 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b
0i0PCcUi (fafff608, fafff6e0, a, 0, 0, 0) + 24
0013328c assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b
0i0PCc (fafff608, fafff6e0, 0, 0, 4e7ce8, ff1b03d8) + 24
0012ff84 __t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc
(fafff608, fafff6e0, ff1b554c, 14, ff1b4fe8, ff1b5670) + 28
00201d70 addFile__12RecordWriterPCcT1i (1440b60, fafff6e0, fafff810, 11, 242000, ff1b554c)
+ 138
00201954 write__12RecordWriterPCvUiUii (1440b60, fafffa50, b8, 1, 11, 0) + 384
我强烈怀疑msync / memcntl与new上的allocate / basic_string发生争执。可能是因为内存分配例程不是线程安全的。这种争用并非每次都发生，但是以不确定的方式，当没有这种争用时，应用程序运行非常顺利而没有任何问题。我的问题是如何避免这种争论？如果我将mutex信号量守卫放在哪里？我是否应该使用我的自定义new / malloc我可以将mutex后卫设为自定义msync？
还有其他方法吗？
请思考。