Overloading operator new
-
Hi, For memory stats we have overloaded the operator new in such a way that it allows us to allocate memory and store information about which module is doing it. This is all great. However, now that we have moved to a multi-threaded environment, do we need to protect the call _malloc_dbg(...) (in a debug build) and the ::operator new(...) (in non-debug) with a critical section? "Programming today is a race between software engineers striving to build bigger and better idiot-proff programs, and the Universe trying to produce bigger and better idiots. So far the Universe is winning." -- Rich Cook
-
Hi, For memory stats we have overloaded the operator new in such a way that it allows us to allocate memory and store information about which module is doing it. This is all great. However, now that we have moved to a multi-threaded environment, do we need to protect the call _malloc_dbg(...) (in a debug build) and the ::operator new(...) (in non-debug) with a critical section? "Programming today is a race between software engineers striving to build bigger and better idiot-proff programs, and the Universe trying to produce bigger and better idiots. So far the Universe is winning." -- Rich Cook
in dos one could access hardware directly because dos's singe-threaded. multi-threaded oses like windows have to take care themselves that hardware pieces are accessed by just one program at a time. this means for you that not you're allocating memory, but the os's doing it for you; you don't need any multithreading resource-locking techniques at all. Я люблю русский язикь!
-
Hi, For memory stats we have overloaded the operator new in such a way that it allows us to allocate memory and store information about which module is doing it. This is all great. However, now that we have moved to a multi-threaded environment, do we need to protect the call _malloc_dbg(...) (in a debug build) and the ::operator new(...) (in non-debug) with a critical section? "Programming today is a race between software engineers striving to build bigger and better idiot-proff programs, and the Universe trying to produce bigger and better idiots. So far the Universe is winning." -- Rich Cook
When you build with the MT (multithreaded) CRTL (c run time library), you will be getting the multithreaded version of new and delete which have built in locking support. You don't have to worry about it. Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
in dos one could access hardware directly because dos's singe-threaded. multi-threaded oses like windows have to take care themselves that hardware pieces are accessed by just one program at a time. this means for you that not you're allocating memory, but the os's doing it for you; you don't need any multithreading resource-locking techniques at all. Я люблю русский язикь!
Multithreaded operating systems do not protect your from accessing hardware at the same time. Two threads can access the same page of memory and cause all sorts of mess if locking isn't used to manage the data in the page. Tim Smith I'm going to patent thought. I have yet to see any prior art.