Multi-Threaded Garbage Collector Problem

Started by
5 comments, last by DudeMiester 18 years, 9 months ago
Ok so I've written this nice multi-threaded partitionable garbage collecter in C++. It's cool because there is no single global collector, but objects can be split between collectors that can have whatever collection algorithm and be schedualed however you want. The default algorithm is thread safe, so you can collect in a background thread while your program runs, and only ever locks down one object at a time so there's rarely interference. When I'm done I'll release the code if someone's interested. Anyways, I have since discovered the joys of debugging multi-threaded programs. To test it I've got two threads, one that just loops and allocates 1 million unsigned integers, and the other that just loops garbage collecting. I'm quite sure the problem isn't my code, as half the time the program runs fine, in ~2s might I add :), and I've ran it in my head dozens of times. Rather, in the other half of the time, I get an allocation error in "new", claiming there's no space when there definitly is (>300MB free RAM). The error doesn't occur if I disable the collector thread, so it clearly is due to the fact I'm deleting and allocating at the same time. However, I'm using the multithreaded run time library (VC++ 7.1 btw), so it shouldn't be a problem. I have no idea at this point. Is there something I'm missing?
[s] [/s]
I can see the fnords.
Advertisement
I'm not 100% sure about threads, but you can't allocate in one DLL/EXE and dealocate in another. Does the same apply to threads? I think it might.
No, all thread/fibers in a program/process share the same memory space.
[s] [/s]
I can see the fnords.
OK, sorry that didn't help [smile]. Just found the same thing (source).

Next question - how are you finding out that it's reporting a lack of memory? Have you managed to wrestle any more information out of the debug heap?

I havn't read it, but this looks interesting.
Actually - I just had a thought - with so much access, is it possible the allocation thread's heap lock is timing out while the dealocation thread does its thing? (I'm afraid I don't know the details of how the heap locks).
"new" throws "bad_alloc", which generally means there is no space, at least according to the MSDN docs. Also the article only covers syncronisation, and nothing I don't already know, but it is a good read for somelme who wants too learn. :)

EDIT: They don't time out. Also the heap locks only during "delete" and "new", no where else.

EDIT 2: It's my code, somehow... I'll hame to do some looking... again.

[Edited by - DudeMiester on July 24, 2005 4:34:33 AM]
[s] [/s]
I can see the fnords.
Fixed it. There was some subtle and some not-so-subtle-I'm-an-idiot errors with syncronisation and collection.
[s] [/s]
I can see the fnords.

This topic is closed to new replies.

Advertisement