Beman Dawes wrote:
On Fri, Apr 17, 2009 at 4:08 AM, Achilleas Margaritis <axilmar@gmail.com> wrote:
I think the question David was asking is; if a GC object is holding a mutex that is currently holding a lock, then when does that lock release, or how does that lock release? The GC may run in the future, and in the meanwhile, that lock is frozen.
Aren't scoped locks a better way to handle such issues? The big advantage of C++ is scoped construction/destruction.
Achilleas, you are missing Dave and Sid's point. It is a common and very appropriate programming practice to place resources like files and mutexes in an object and to dynamically allocate that object. If GC is used to reclaim the containing that object, then sub-objects it contains like mutexes or files that release on destruction may not get released soon enough. You need to address this concern. Telling folks not to place non-memory resources in types that may be dynamically allocated isn't likely to fly.
If objects like files and mutexes are dynamically allocated, then they are deleted at some point, aren't they? so, if the programmer wants to add garbage collection to these objects, so he/she doesn't have to manually track memory, he/she can replace the delete operations with RAII and let the GC handle the memory part. The order or finalization is not a solvable problem by any means, so I don't see how a solution can be provided. In c++, the order of creation is not guaranteed to be the same to the order of allocation, so it is not possible to have a real generic solution for that. Still, RAII can easily replace delete calls: instead of deleting an object, you simply close it or unlock it and you let the gc decide if the object is reachable or not.