|
How about you take the feedback more gracefully?
|
|
|
|
|
What EXACTLY is the feedback you're talking about?
The OP asks a question, and I suspect a design flaw has lead him to ask it. I answer his original query, and then ask him a followup question which will help me understand if his design is flawed. And then you show out of nowhere to tell me that I'm asking an "invalid question", which serves absolutely no purpose. But you seem to be thinking that you've given me "graceful feedback".
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Thanks Rajesh & Randor for the answer,
Ops!! I am a bit late in answering. I will surely check for that quota limit error ERROR_NOT_ENOUGH_QUOTA, not sure if that is the problem.
My application is a trading application and each millisecond is important in that. The problem happens while I postmessage on a window to add/update the value in that. PostMessage happens on every status change of an order. There are multiple orders and status change happens in approx every 200 milliseconds. Most of time everything works fine but sometimes it misses messages.
Thanks for the follow-up question. Thank albert for participating.
|
|
|
|
|
Nothing wrong with posting a lot of messages, windows posts a ridiculous number of messages for handling window drawing. Video games do the same for drawing smoothly. Good luck! 
|
|
|
|
|
Thanks Albert,
That's what I was doing till now but it could not work. To confirm this issue, I made one test project. I had posted 10005 messages on a dialog with different scenarios.
Scenario 1: I sent all the messages using a "for" loop
for(....)
{
::PostMessage(.....);
Or
::PostThreadMessage(....);
}
Scenario 2: I added a Sleep statement after Posting message. (I am not using Sleep in my project, it was just for testing purpose)
I run both the scenarios 10 times. Messages were missed only once. MessageCount was 9993 instead of 10000. I know last 5 will miss for sure. This does not happen frequently so it's difficult to reproduce.
My live project is still under testing so waiting for it's test result.
|
|
|
|
|
Are you processing these on the main GUI thread? ...if so, try just posting between two threads that do nothing except for catching/sending messages. The main GUI thread gets a lot of overhead messages from Windows (specially when drawing).
|
|
|
|
|
I can't think of any other reason for why some messages should go missing, except for if the queue is full. You can try increasing the message queue size (Google for this - a registry key can be modified to achieve this). If performance is of so much importance, I'd think of dropping MFC and switching to something lower (like STL) because you're now having the added overhead of MFC.
I hope you're using multiple threads (if not, it's about time you did). I could even think of using a thread pool in a scenario like this. If nothing, you could accept all messages and put it into data structure (so that the message is popped off the queue immediately), and then process messages from that data structure.
I think some redesigning may be required, based on your application's requirements.
Another person is telling you to go ahead and post messages like crazy, but that sounds like bad advice to me because that clearly is not working (the very reason why you started this thread).
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Thanks Rajesh,
I had tried CList to prevent data loss while message was not deliver. In fact Clist is what which is currently working in my project to prevent data loss. Instead of sending the data in WPARAM and LPARAM, I am adding those to CList and removing them from CList at the message-handler side. So even if a message misses, another successful message removes all the pending values in the CList. I think I need thread pool also to give better concurrency. Thanks I will look into it. Definitely I am using multiple threads. Each does it's own work. I think it can be still optimized by using thread pool.
Thanks
- Rahul
|
|
|
|
|
Don't forget to use a mutex (or something similar) to keep threads from accessing the CList simultaneously. That can cause major problems (that will be very hard to fix later on since its hard to diagnose a problem like this).
|
|
|
|
|
And Oh, you're absolutely nobody here to tell me to stop posting. If you can't provide meaningful feedback, probably you should stop your act here.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Again... Grow up and take feedback more gracefully.
|
|
|
|
|
Read the whole thing again and you'll know may be you should grow up and not me.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
The follow-up question is actually very good and far more important (in my opinion) than the original question. It's probably a good idea to consider a redesign when you are handling so many messages - either they are superfluous or a different mechanism of communication is appropriate.
|
|
|
|
|
|
Hi Rahul,
I believe that the default message queue size is around 10000 messages and can be changed through the registry. It is possible although unlikely that you are exceeding this limit. As Rajesh pointed out you can check for this condition by checking the return value for ERROR_NOT_ENOUGH_QUOTA.
A more likely scenario would be that your thread is interacting with a UI object or modeless dialog and the thread message is being eaten. I would recommend that you check your thread code to make sure that you are not doing anything UI related. Never launch a modal dialog from a worker thread if you expect the thread to be able to recieve thread messages. Instead... have your worker thread post a message back to the main thread and allow that thread to create/manage dialogs.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks for the reply, I will check for that limitation also but I think I should not change it in registry.
|
|
|
|
|
Hi Experts,
I have a application (Sever and client) which used 2 port to communicate with client. But If i forcefully closes the client applicatiom, server application uses 99% cpy usage.
And I also checked all the recieving and sending threads, all are fine.
I could not figur it out.
|
|
|
|
|
And you think we will be able to figure it out without seeing anything of it? Please provide some code sniplets, preferably from the server. This does not mean the whole code.
Generally speaking:
You probably have a run-away thread (a thread that has a -possible- infinite loop that eats up the CPU). Try running your server with a debugger and when you see the high CPU usage, pause it and step trough the code to see what it does. If you see it running in circles, there you have it...
Try adding sleep(1) or such to let other threads breathe too.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
|
rahul.kulshreshtha wrote: If debugging is not possible then write into filesget another job
If he cant debug he shouldn't be writing code.
==============================
Nothing to say.
|
|
|
|
|
john5632 wrote: And I also checked all the recieving and sending threads, all are fine.
No they arent.
You have a server thread that is hogging the CPU when the client drops comms.
==============================
Nothing to say.
|
|
|
|
|
The most common cause of applications looping when communication closes is improper handling of the error returns from the various functions.
When you shutdown one end of a communications path the other end will recieve an error code or some other indication that the path is no longer functional. You are probably not handling those correctly. That's the first place I would look.
|
|
|
|
|
Hi,
I am using CMap. While adding and deleting elements I am using Locks because there are multiple threads  Do I need to put lock before using pLookup function? Sometimes it crashes while looking up for an element. My lookup statement is like below :
if(cmap_buffer.PLookup(element.orderId) != NULL)
st_order = cmap_buffer[element.orderId];
Thanks,
Rahul Kulshreshtha
|
|
|
|
|
It is not thread safe. You will have to manually add the locking before accessing its data. Imagine what would happen if a node is removed while PLookup is using it.
The easies way of creating a thread safe container is to embed an existing container in a new class with the same interface, or a subset thereof if sufficient, forwarding all calls to the aggregated container and adding all the locking in between.
|
|
|
|
|
Thanks Niklas,
Using a thread-safe container will be a good solution. I wish Microsoft should provide some in-built thread-safe containers. As currently there is no inbuilt thread-safe way so I will go for creating my own. But I will not be able to use it in this project because it is 90% completed and implementing a new container and replacing it over existing map will take a big code-patching.
Thanks, I will take care this next time.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
