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.
>
>
>
>
| Вернуться в корень Архива
|