Am 23.04.2012 13:57, schrieb Steven Schveighoffer:
On Mon, 23 Apr 2012 02:41:21 -0400, Benjamin Thaut
<[email protected]> wrote:
I wrote a small "bad example" program for a presentation. It calls
malloc/free very frequently and I wanted to profile the impact of this
compared to a pool allocator solution. Unfortunately I had to notice
that the program only runs for a fraction of a second before
deadlocking. As it seems the following situation accurs:
1) Thread 1 calls malloc(), and locks the internal malloc mutex
2) Thread 2 triggers garbage collection and stops thread 1
3) Thread 2 is done collecting garbage and calls all destructors. One
of these calls free(), as the malloc mutex is still locked by Thread 1
and Thread 1 will never release the mutex, as it is stoped, Thread 2
deadlocks.
This shouldn't happen. The collection routine is specifically designed
to avoid this. I remember when Sean put it into Tango after an IRC
conversation.
The correct sequence is:
1. stop the world
2. Perform mark on all data (identifying which blocks should be freed)
3. resume the world
4. Call dtors on unreferenced data and deallocate.
This was to fix the exact problem you are having, albeit the malloc/free
were indirect by calls to C-libs.
Please file a bug.
-Steve
If what you are saying is true, the deadlock must happen somewhere else.
This was kind of a assumption because the deadlock happend after I added
all the malloc / free calls. Because all the threads are stopped when
this happens I can't really debug this, because the Visual Studio
debugger tells me that it can not debug any thread but the one that is
currently running the GC.
Kind Regards
Ingrater
