Is the operator new() thread-safe?

[Travis Craig]

We are seeing some strange process crashes that have only occurred on multi-processor machines, so far, with new[] and new at the top of the readable portion of the traceback. The process has a number of pthreads and is linked multithreaded, with upcalls turned on. The sysgen parameter MULTIPROCESSING is 3 and MULTITHREAD is 2. I feel sure that the C++ new operator would be thread-safe, but does anybody know for sure. The system has VMS V7.3-1 with patches through October 2004 and probably C++ V6.5. I can find out more precisely if it would make a difference.

[Ian Miller.]

have you seen the comments here
http://h71000.www7.hp.com/commercial/cplus/docs/6026pro_intr.html#index_x_3
http://h71000.www7.hp.com/commercial/cplus/docs/6026pro_iostr.html#index_x_103
http://h71000.www7.hp.com/commercial/cplus/docs/6026pro_vect.html#index_x_515

[John Gillings]

Craig,

What is the error that the process crashes on? ACCVIO? Quota limit? etc...

Do you know if your process is splitting into multiple kernel threads?

Does the problem go away if you reduce MULTITHREAD to 1? What about if you put a jacket around new() and use a mutex to prevent it from being executed by two threads simultaneously?

Have you tried looking at a process dump to try and determine the state of any other threads?

[Travis Craig]

Thanks, Ian. Those references say the standard library is thread-safe, which I feel strongly implies that new is thread-safe, although I haven't seen it written anywhere.

John,

It crashed on:

CXXL-F-EXCEPTION, Exception thrown at PC =
. . . traceback . . .
CMA-F-EXIT_THREAD, current thread has been requested to exit

I just looked back and found that this particular crash, with new at the top of the stack, probably happened only before they set MULTITHREAD to 1. I don't see where it happened since then. (A bunch of other things have gone wrong now.) We didn't use a mutex to protect calls to new, pending the answers to this thread, because we were hoping someone would say it is thread-safe.

I have looked at what I have, tracebacks. I don't have any dumps. Is there a way to see something about the pthreads in a process? From ANAL/SYS, I can only see the kernel threads. The only place I've been able to see anything about the pthreads is from inside the debugger.

For now, I'm rebuilding our system with some changed defines for Rogue Wave, because I'm not sure it was built multi-threaded enough. That brings up some different questions that I'll put in a separate thread if I have time.

--Travis

[Bojan Nemec · Accepted solution]

Travis,

Can you setup that process for process dump with one of this commands:
$ SET PROCESS/DUMP/ID=pid

or if you start the process with the run command:

$ RUN/DUMP ...

or if the process is created with SYS$CREPRC setting the PRC$M_IMGDMP flag in the stsflg parameter.

This will produce an SYS$LOGIN:.DMP file, when the image exits with an unhandled error. When you get this file, you can examine it with the ANALIZE/IMAGE SYS$LOGIN:.DMP command, which brings you in an debugger like environment.

Bojan

[Travis Craig]

Thanks, Bojan. This problem was solved, we hope, by going to one kernel thread per process or compiling for greater thread safety. I used the /DUMP qualifier for a different problem, though, and it was definitely a 10-pointer. It eventually led me to find a bug in time.h.