Multi-threading and CMap / CList MFC classes
in [MFC]
|
From: Olivier on 22 Mar 2010 06:02 Hello MFC gurus, (1) Is it legal to allocate (using "new" operator) a CMap / CList object in one thread and destoyed it (using "delete" operator) in another one? (2) Is it legal to access a CMap / CList MFC object in different threads (using a "mutex" to control access to the shared object)? Thanks in advance Best regards, Olivier.
From: Olivier on 22 Mar 2010 06:15 Also, FYI, I use MFC as shared dll + multi-threaded CRT (dll) Olivier. "Olivier" <toon(a)toonworld.com> a �crit dans le message de news: ON%23TDbayKHA.6140(a)TK2MSFTNGP05.phx.gbl... > Hello MFC gurus, > > (1) Is it legal to allocate (using "new" operator) a CMap / CList object > in one thread and destoyed it (using "delete" operator) in another one? > (2) Is it legal to access a CMap / CList MFC object in different threads > (using a "mutex" to control access to the shared object)? > > Thanks in advance > > Best regards, > > Olivier. > >
From: Goran on 22 Mar 2010 07:24 On Mar 22, 11:02 am, "Olivier" <t...(a)toonworld.com> wrote: > (1) Is it legal to allocate (using "new" operator) a CMap / CList object in > one thread and destoyed it (using "delete" operator) in another one? Yes. You must ensure that no other thread uses pointed-to object while you're deleting it (nor after, of course). Note that your question is orthogonal to CMap or CList. CMap and CList are created/destroyed through MFC operators new and delete, and these are of course thread safe. If they weren't, MFC would have been much less useful. In fact, any thread-unsafe heap manipulation, including implementations of new/delete, would have been much less useful. > (2) Is it legal to access a CMap / CList MFC object in different threads > (using a "mutex" to control access to the shared object)? Yes. By the way, in MFC, mutex you are looking for is likely CCriticalSection, not CMutex. In a way, bigger question you have is "what are multithreading ramifications when working with MFC containers". The answer is: they are not thread safe, you have to do that. Goran.
From: Scott McPhillips [MVP] on 22 Mar 2010 09:15 "Olivier" <toon(a)toonworld.com> wrote in message news:ON%23TDbayKHA.6140(a)TK2MSFTNGP05.phx.gbl... > Hello MFC gurus, > > (1) Is it legal to allocate (using "new" operator) a CMap / CList object > in one thread and destoyed it (using "delete" operator) in another one? > (2) Is it legal to access a CMap / CList MFC object in different threads > (using a "mutex" to control access to the shared object)? Yes and yes. Within threads of the same process you can use EnterCriticalSection/LeaveCriticalSection for the synchronization, which is lower overhead than using mutex. -- Scott McPhillips [VC++ MVP]
From: Joseph M. Newcomer on 22 Mar 2010 10:46
See below... On Mon, 22 Mar 2010 11:02:44 +0100, "Olivier" <toon(a)toonworld.com> wrote: >Hello MFC gurus, > >(1) Is it legal to allocate (using "new" operator) a CMap / CList object in >one thread and destoyed it (using "delete" operator) in another one? **** Simplistically, yes, this is not only legal, but often used to pass information between two threads. THe real truth is both threads must share a common storage allocation mechanism, so it is not thread context alone that is the factor. If the thread was created in a DLL that had, for exmaple, a atatically-linkf C runtime, then that DLL has its own private storage allocation mechanism, disjoint from that of its callers. Consequently, only the code running in the DLL is permitted to call delete, so you would not use 'new' and 'delete' in their raw forms outside the DLL, or mix them with one outside the DLL and one inside. So the real point is what storage allocator is being used. To be completely correct, your DLL has to provide operations to allocate and destroy objects, and in the case of collections, the objects in the collections must be allocated and deleted by the same allocator as well,. **** >(2) Is it legal to access a CMap / CList MFC object in different threads >(using a "mutex" to control access to the shared object)? > >Thanks in advance **** Normally, you would not use a mutex, but a CRITICAL_SECTION, to do mutual exclusion. A mutex is a heavy-duty object, requiring a kernel call to query, and if the mutex cannot be acquired, the kernel deschedules the calling thread and queues it up to be reactivated (as one of a set of threads that are pending) when the mutex is released. Note that there is no specified algorithm for reactivation, nor are there anti-starvation guarantees. A CRITICAL_SECION, by comparison, requires no kernel call to acquire, and if it the C_S cannot be acuired, the program enters a spin-loop test ("are we there yet?") for a small number of microseconds before calling the kernel to deschedule the thread. Generally, your locking is for incredily short periods (perhaps 10s of nanoseconds) and this is actually lower overhead. So don't use a Mutex object (CreateMutex) unless you need mutex capabilities (waitable object, has timeouts, can be used in a WaitForMulipleObjects call to allow other exit conditions such as an abort-this-operation request). But I always ask, "Why do you need concurrent access?" and in a well-engineered system you don't always need or want concurrent access. So I always consider the introduction of any mutual exclusion primitive to suggest strongly that the design is wrong. It isn't always the the case, but it is a strong indicator most of the time. joe **** > >Best regards, > >Olivier. > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |