CSingleLock && CCriticalSection
Mario Contestabile -- Mario_Contestabile.UOS__MTL@UOSMTL2.universal.com Friday, December 27, 1996 Environment: MSVC 4.2b, Windows 95 It has been said on and off this list that using a CCriticalSection pointer in a CSingleLock object won't work, contradicting the documentation. A simple trial program similar to CSingleLock csl(&m_CSect); if(csl.Lock()) proved to work correctly and showed no assertions. Anyone experience unpredictable or odd behavior using these two objects together? mcontest@universal.com
Mike Blaszczak -- mikeblas@nwlink.com Saturday, December 28, 1996 At 10:48 12/27/96 EDT, Mario Contestabile wrote: >Environment: MSVC 4.2b, Windows 95 >It has been said on and off this list that using a >CCriticalSection pointer in a CSingleLock object >won't work, contradicting the documentation. >A simple trial program similar to >CSingleLock csl(&m_CSect); >if(csl.Lock()) >proved to work correctly and showed no assertions. >Anyone experience unpredictable or odd >behavior using these two objects together? It's fine to do so. It's CMultiLock that doesn't like to use pointers to CCriticalSection objects, mainly because there's no API to implement that kind of behaviour. .B ekiM http://www.nwlink.com/~mikeblas/ <-- trip report central! 95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7 Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel I am bored of this talk. It is time now for the dancing! These words are my own - I do not speak on behalf of Microsoft.
Sam Gentile -- sgentile@gensym.com Wednesday, January 08, 1997 At 09:41 PM 12/28/96 -0800, you wrote: >At 10:48 12/27/96 EDT, Mario Contestabile wrote: >>Environment: MSVC 4.2b, Windows 95 > >>It has been said on and off this list that using a >>CCriticalSection pointer in a CSingleLock object >>won't work, contradicting the documentation. >>A simple trial program similar to > >>CSingleLock csl(&m_CSect); >>if(csl.Lock()) > I have a section of code where CSingleLock just isn't working. The weird thing is that it works in about 10 other parts of the ode. The code: CSingleLock csl(&m_critGsiInterface); csl.Lock(); // switch on the type of GSI data type switch (gsi_type_of(gsiArguments)) { m_critGsiInterface is a CCritcalSection. When I reach the switch statement, as I watch in the debugger, the other thread that is supposed to be locked out begins to run. I can't figure what's wrong since it is the same code that runs in like 10 other places. Is this some mkind of known problem? Is there a way around this? Thanks, Sam >>proved to work correctly and showed no assertions. >>Anyone experience unpredictable or odd >>behavior using these two objects together? > >It's fine to do so. It's CMultiLock that doesn't like >to use pointers to CCriticalSection objects, mainly because >there's no API to implement that kind of behaviour. > > > >.B ekiM >http://www.nwlink.com/~mikeblas/ <-- trip report central! >95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7 >Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel > I am bored of this talk. It is time now for the dancing! >These words are my own - I do not speak on behalf of Microsoft. > > > >
| Вернуться в корень Архива |