|
Luckily, it works. But that's a good point there. I will modify my previous post.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Hi all,
I am having a list(queue)of tasks. My two threads are using the same list.
First thread is to insert the task into it. (appending the list)
Second thread is to process on each task . ( reading the list)
My aim is to give the maximum availability to Thread one without hanging thread two.
How to synchronize both thread so that, second thread should not wait for long and First thread keep inserting the item into list.
Thanks in advance
|
|
|
|
|
critical section! look for CCriticalSection class in MFC!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/xml>
|
|
|
|
|
A piece of good advice is to stay clear of the MFC synchronization objects because they are not working properly. They may fail under certain circumstances.
E.g. you cannot recursively lock a CCriticalSection from the same thread because it will cause a deadlock.
Use the Win32 API with ::EnterCriticalSection() and ::LeaveCriticalSection() instead.
Read more here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: E.g. you cannot recursively lock a CCriticalSection from the same thread because it will cause a deadlock.
 Wow, thanks for the info Roger. I've never used the MFC sync objects before but I don't think I will ever use them now.
|
|
|
|
|
Yup, pretty amazing, isn't it?
But the evidence is right there in the code. 
I've never used the MFC sync classes since I read Joe's advice many years ago in a much earlier essay of his.
Even though CCriticalSection may work if it's only locked once in a call chain, you will eventually find yourself in a situation where you should perform a second lock due to encapsulation and at that time you're smoked; a re-write using the Win32 primitives is essential before it has a chance of working.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hey Guys,
I have always used MFC, but now that I have upgraded to visual studio 2005 and 2008 I am forced to use MSI installers due to the depencies on the new merge modules. I really don't like the msi installer I think it's horrible and I would rather use inno setup or the old wise installer.
I just want to be sure.... If I was to start writing all my code in a pure Win32 Application from vs 2005 or 2008 I would no longer require the vcredist files in order to run my applications correct?
Thanks,
Greg
|
|
|
|
|
Your application will still depend on CRT DLL's.
You don't necessarily have to use MSI or other installers. You can always deploy you application using private assemblies. Read this article http://www.codeproject.com/KB/cpp/vcredists_x86.aspx[^], for more details. There is a section on "Install a private assembly".
-Saurabh
|
|
|
|
|
Thank you very much! 
|
|
|
|
|
You are welcome.
-Saurabh
|
|
|
|
|
You may also link with static CRT library.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I generally don't advise doing that since in long run it might create very obscure bugs. If you link application with static CRT and later on use a library which was linked dynamically with CRT then it might create all sorts of problems from multiple defined symbols during linking to incorrect handling of resources.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: If you link application with static CRT and later on use a library which was linked dynamically with CRT then it might create all sorts of problems from multiple defined symbols during linking to incorrect handling of resources.
Well, the above is not, IMHO, an obscure bug.
Statically linking the CRT ramain a valid option, IMHO.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Linking with static CRT is definitely a valid option. I call such bugs obscure because sometimes a 3rd party library can be added long after choosing to link with static CRT and suddenly a working application might start crashing.
-Saurabh
|
|
|
|
|
I guess that's an old (or maybe funny for you masters  ) question! but I'm so weak in googling! could you please give me some information or something? I'm using MFC...
Thank you masters!
|
|
|
|
|
See Here[^]
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
Thank you ...
Thank you masters!
|
|
|
|
|
|
متشکرم آقا حمید
Thank you masters!
|
|
|
|
|
You're welcome.
|
|
|
|
|
Hi. Ive got a simple Visual C++ application (non-managed; Visual C++ version 7). I need a folder-tree control that lets the user search thru the folder tree, then select a single folder. I dont need anything fancy (such as multiple selections, etc). Also, I cant use anything that relies on recent Visual C++ features because I've got an older version. I dont need to fill the tree with my own custom data: I just want the tree software to automatically populate the tree from the disk drive (based on soom root folder I give it). I looked at the list of Tree Controls at:
http://www.codeproject.com/KB/tree
but it is a bit overwhelming. Can anyone suggest a tree control that is simple, mature, and works with Vis C++ version 7?
Thanks in advance.
zoom
modified on Thursday, October 2, 2008 7:54 PM
|
|
|
|
|
|
We have a medical imaging application. Recently one our processes crashes after a particular workflow and from the user.dmp thus created its getting extremely difficult to trace down the issue. Its not always that the process crashes after this workflow. But rarely it does and thats what giving half the team sleepless nights.. Am attaching below the callstack which I am getting. Any leads on this would be highly appreciated. Thanks in advance.
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 0ce17c50
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 0cf4d1a9
Attempt to write to address 0cf4d1a9
DEFAULT_BUCKET_ID: CODE_RUNNING_ON_HEAP
PROCESS_NAME: CapGM.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
WRITE_ADDRESS: 0cf4d1a9
BUGCHECK_STR: ACCESS_VIOLATION
EXCEPTION_DOESNOT_MATCH_CODE: This indicates a hardware error.
Instruction at 0ce17c50 does not read/write to 0cf4d1a9
IP_ON_HEAP: 0ce17c50
LAST_CONTROL_TRANSFER: from 77600f3d to 0ce17c50
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
0e86f9d0 77600f3d 0d03f7c8 774ecc08 0e86fa00 0xce17c50
0e86f9f0 77600ee9 0b8be5ac 0b8d3bc8 0d03f7c8 ole32!CChannelHandle::CChannelHandle+0xc6
0e86fa38 77600ba0 0b8be5ac 001d5550 0b8c4558 ole32!CRpcChannelBuffer::ClientGetBuffer+0x2b1
0e86fa88 7751317f 0b8be5ac 0b8c4558 0b8d3bc8 ole32!WdtpRemotableHandle_UserUnmarshal+0xc
0e86fb60 775130a4 0b8b5e80 00000000 0b8d3bc8 ole32!COAHolder::Release+0xd
0e86fb7c 776007f5 0b8be5ac 00000001 0b8d3bc8 ole32!CPubDocFile::Stat+0x4e
0e86fbac 77602dd8 0b8be558 0b8b5e80 0b8d3bc8 ole32!CRpcChannelBuffer::ClientGetBuffer+0x451
0e86fbb8 0b8d3bc8 0d03f7c8 0015ac18 0b8a1e00 ole32!LocalCall+0xc
0e86fc80 77600715 0b8be558 0b8a1e00 001d5538 0xb8d3bc8
0e86fccc 77e794a5 001d5264 001d5538 001d5264 ole32!CRpcChannelBuffer::ClientGetBuffer+0x2a6
0e86fd00 77e7940a 776005d0 001d5264 0e86fdec rpcrt4!NdrFreeBuffer+0x19
0e86fd54 77e79336 00000000 00000000 774ebfc8 rpcrt4!NdrGetBuffer+0x5
0e86fd78 77e8a33c 001d5264 00000000 774ebfc8 rpcrt4!MTSyntaxBinding::FindOrCreateBinding+0x99
0e86fdb8 77e8a37d 001d5264 001d5220 00000000 rpcrt4!LRPC_CCONTEXT::RemoveReference+0x1f
0e86fdf8 77e7bc99 0b9347f0 0016e490 001d5008 rpcrt4!LRPC_CASSOCIATION::AllocateCCall+0xa1
0e86fe1c 77e7bbdd 0016e4cc 0e86fe38 001d5008 rpcrt4!LRPC_SCALL::DealWithRequestMessage+0x14a
0e86ff80 77e76c9f 0e86ffa8 77e76ac1 0016e490 rpcrt4!LRPC_SCALL::DealWithRequestMessage+0x1
0e86ff88 77e76ac1 0016e490 7c9106eb 00000000 rpcrt4!LRPC_ADDRESS::ReceiveLotsaCalls+0x460
0e86ffa8 77e76c87 00160008 0e86ffec 7c80b683 rpcrt4!BaseCachedThreadRoutine+0xf4
0e86ffb4 7c80b683 0b8d7e20 7c9106eb 00000000 rpcrt4!LRPC_ADDRESS::ReceiveLotsaCalls+0x448
0e86ffec 00000000 77e76c6d 0b8d7e20 00000000 kernel32!IsDBCSLeadByte+0x2c
FAULTING_THREAD: 00001810
FOLLOWUP_IP:
ole32!CChannelHandle::CChannelHandle+c6
77600f3d ?? ???
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: ole32!CChannelHandle::CChannelHandle+c6
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ole32
IMAGE_NAME: ole32.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 42e5ba18
STACK_COMMAND: ~61s; .ecxr ; kb
FAILURE_BUCKET_ID: ACCESS_VIOLATION_CODE_ADDRESS_MISMATCH_ole32!CChannelHandle::CChannelHandle+c6
BUCKET_ID: ACCESS_VIOLATION_CODE_ADDRESS_MISMATCH_ole32!CChannelHandle::CChannelHandle+c6
Followup: MachineOwner
---------
|
|
|
|
|
good for you,
you probably need to check CChannelHandle or ClientGetBuffer
|
|
|
|
|
None of what you see in the callstack are my functions. Its all from ole32.dll
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
