|
I think adjusting thread priority is not a reliable fix for the flaw on your syncrhonization mechanism.
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]
|
|
|
|
|
Hi,
Me too think so, even though it seems working, It would be better If I fix it in some other proper way and not by just priority or timing.
Thanks & Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
I didn't fully understand what you were saying but I understood that the problem was because your buffer was accessed by two threads and you have problems when one is writing in it while the other is reading it (which is logical). If that's your problem, why don't you access the buffer in a critical section ? This way, only one thread will be able to access the buffer at a time and this will avoid having data corruption.
|
|
|
|
|
Hi,
I will try If I can use critical section.
Problem is data is written into a single ring buffer.
If I use critical section, then other thread cannot access any part of ring buffer until write finish.
I want to let other thread to read the messages written completely by write thread(callback) and not current message being written.
One way is, I can check write pointer location, if the message not complete, then reset the read pointer to current message starting byte and check for complete message again.
Thanks for your help, I will try this tomorrow in office and update after I fix it.
Thanks & Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Another option is to update the write pointer only when you have written your message completely.
|
|
|
|
|
Cedric Moonen wrote: Another option is to update the write pointer only when you have written your message completely.
Hi,
It is fixed now by your idea and there is no overrun.
Thanks for your great suggestion!!
Regards,
Suman
--
"Programming is an art that fights back!"
|
|
|
|
|
Hi,
I am facing a problem while accessing values in a std::list in release build. The code I am using is like
struct _STRUCT_ABC
{
int iIdCount;
string szName;
}STRUCTABC, *PSTRUCTABC;
list<<PSTRUCTABC>>:: iterator ittr = g_ABCList.begin(); // g_ABCList is a golbal list with PSTRUCTABC
int iCount = ittr._Ptr->_Myval->iIdCount; // Works fine with _DEBUG prepocessor but does not work in release mode if _DEBUG prepocessor is not defined.
Now according to VS2005 compiler _Ptr is a private variable if _DEBUG is not defined. In that case how to access the values inside the list?
Thanks in advance.
|
|
|
|
|
Aryan S wrote: int iCount = ittr._Ptr->_Myval->iIdCount;
you don't like the public interface of the list (and its iterator), do you?
int iCount = ittr->iIdCount;
int iCount = (*ittr)->iIdCount;
[thanks to]
Cedric's post
[/thanks to]
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]
modified on Monday, June 23, 2008 5:32 AM
|
|
|
|
|
What are you doing ?
That's not the way to work with iterators. You hsould simply dereference them:
int iCount = (*ittr)->iIdCount;
|
|
|
|
|
Thanks!!!
I am actually new in this field...
|
|
|
|
|
Aryan S wrote: I am actually new in this field...
There are a lot of tutorials on the web, it would be much more efficient to read some of them before going any further developing code with tools that you don't how to use.
Check this[^] for instance.
|
|
|
|
|
I have a few controls like button , list box and combo box on my dialog in a dialog based application. I use tab key to change focus on controls hence the OnkIllFocus for the controls is executed as i tab . But When i close the dialog OnkIllFocus for the last control having the focus is not executed.I want to know the reason why this happens .
I expect the current control having focus shud lose Focus on closing Dialog hence OnkIllFocus for that control shud be called.If i am wrong plz correct me.
|
|
|
|
|
Shaileshhex wrote: I want to know the reason why this happens .
Maybe because the WM_KILLFOCUS message is not generated at that point. Use Spy++ to verify.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello, everybody. There is a such problem: it is impossible to process the 2-dimens. array, no problems arise when i allocate memory using malloc, but next lines of code brings computer to stop:
for(row=0; row<=2303; row++){
for(col=0; col<=3071; col++)
Arr[row][col]=....;
}
mmm..How solve this?
|
|
|
|
|
Rustik wrote: but next lines of code brings computer to stop
What do you mean ? Your computer really stops ? Or your program just crashes ?
How is your array declared ? Are you sure you don't go outside the bounds of your array ? Remeber that C arrays are 0 indexed.
|
|
|
|
|
Declaration: int ArrayName[rowSize][colSize]={{0},{0}};
...excuse me for my bad english, i mean program crashes.
|
|
|
|
|
Your program possibly crashes because your array size exceeds the stack one. Try to use the heap, instead.
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]
|
|
|
|
|
it's not clear. Plz explain.
|
|
|
|
|
the size of your array (assuming its elements are int ) is 2304 * 3072 * sizeof(int)= 2304 * 3072 * 4 = 28311552 bytes , while the default stack size for an application is (according to MSDN [^]) 1 Megabyte , i.e. 1048576 bytes .
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]
|
|
|
|
|
Unfair damn voting[^]
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Balanced.
BTW did you remenber to feed your troll this morning?
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]
|
|
|
|
|
Thanks for the vote as usual. There's a troll (only one) and I keep forgetting to feed it.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Is it all?..i mean is there a place in the code, where you have declared :"Now we use heap" ...thanks anyway. I'll try it in my coding and give answer about result.
|
|
|
|
|
Well a C/C++ developer should be able to use both the stack and the heap. I.e. good tutorial needed.
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]
|
|
|
|
|
You were given a good hint, insteads of complaining... why don't you try to search a bit what that clues mean and then re ask if you don't understand it?
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|