Are the _d_arrayappend functions, thread-safe?

Jeff Davey jeffd at gwava.com
Mon Jun 18 13:01:00 PDT 2007


I've recently been having problems with a small SMTP app when I have serious multi-threaded load on linux (compiled with DMD 1.016).

At first, it started with anything that uses std.string.format, and dies in _d_arrayappendcT.. so I removed all calls to anything that uses that module:


(gdb) bt
#0  0x0806b233 in _d_arrayappendcT ()
#1  0x080628d1 in _D3std3utf6encodeFKAawZv ()
#2  0x08055bac in _D3std6string6formatFYAa4putcMFwZv ()
#3  0x08064ddc in _D3std6format8doFormatFDFwZvAC8TypeInfoPvZv ()
#4  0x08055b91 in _D3std6string6formatFYAa ()
Die: DW_TAG_<unknown> (abbrev = 6, offset = 324)
        has children: FALSE
        attributes:
                DW_AT_byte_size (DW_FORM_data1) constant: 8
                DW_AT_type (DW_FORM_ref4) constant ref: 307 (adjusted)
Dwarf Error: Cannot find type of die [in module /root/smtp]


The next place this problem occurred is std.string.split, with again, the _d_arrayappendcT function:

(gdb) bt
#0  0x0806b1eb in _d_arrayappendcT ()
#1  0x08054359 in _D3std6string5splitFAaZAAa ()
Die: DW_TAG_<unknown> (abbrev = 6, offset = 324)
        has children: FALSE
        attributes:
                DW_AT_byte_size (DW_FORM_data1) constant: 8
                DW_AT_type (DW_FORM_ref4) constant ref: 307 (adjusted)
Dwarf Error: Cannot find type of die [in module /root/smtp]


So, I removed the std.string.split calls, and wrote my own that pre-allocated the array rather than appends to it, and that fixed that issue.

And then, somewhere else (where I just have a regular array append):
(gdb) bt
#0  0xf7e3a32c in memcpy () from /lib32/libc.so.6
#1  0x0806b02d in _d_arrayappendT ()
Die: DW_TAG_<unknown> (abbrev = 6, offset = 324)
        has children: FALSE
        attributes:
                DW_AT_byte_size (DW_FORM_data1) constant: 8
                DW_AT_type (DW_FORM_ref4) constant ref: 307 (adjusted)
Dwarf Error: Cannot find type of die [in module /root/smtp]

This time, it's in a slightly different function _d_arrayappendT.

Basically the software has about 200 receiving threads, and is receiving around 60mbit/s of network traffic in a stress test. 

It's definitely thread related, as running it with only one thread it performs fine through 130,000 different emails.

The threading model is fairly simple, accept a socket, pass that socket to a working thread, let the working thread clean up that socket. 

The only globals being used (other than anything in phobos) are contained to a wrapper "SocketStream" class, that has private variables, and one stream per class is created during the beginning of the work phase.

I'm "pretty" certain it's not something on my side, but I would like to be mistaken.



More information about the Digitalmars-d mailing list