|
The key is in the piece of pseucode:
for (I=0; I < 5; ++I)
B->loadData(i); This feeds the cache with 5 ints, signalling dwRun after inserting each int. So, imagine the following (possible) pattern of execution:- A feeds the 1st
int.
- A sets
dwRun.
- The system yields controls to B.
- B processes the cache (containing only one
int) and sets dwWait.
- The system yields controls to A.
- A loads the remaining four
ints, setting dwRun after each insertion.
- A
Waits and exits immediately, as dwWait is already set. There's still some data in B's cache.
See the problem now?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for your help and time, Joaquín 
I see, so the event is already set by the time the wait function is called by A. Thus that is why Thread A does not always wait for Thread B. So how would one go about fixing this dilemma? Perhaps by putting another mutex around the wait function call? Or maybe use a while loop in the Wait function that checks if the vector is empty? Are there any examples of something like this that I could refer to?
Example:
void Wait() // While loop checking size of vector.
{
while (vI.size() != 0)
WaitForSingleObject(dwWait, INFINITE);
} // But this does not seem like a very clean solution.
Thanks again for your help.
Ken
|
|
|
|
|
The easiest solution is probably to split LoadData into two functions, say LoadData and Run, the first feeding the cache and the second setting dwRun, and call Run only when finished pushing the data.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks again. 
Another possible solution that I came up with, which is to reset dwWait in the Wait function. This seems to work???  But I'm wondering if there is an even cleaner way to solve this? 
Example:
void Wait()
{
if (vI.size() != 0)
{
ResetEvent(dwWait); // This will make sure to wait for event.
WaitForSingleObject(dwWait, INFINITE);
}
}
Thanks for all of the help.
Ken
|
|
|
|
|
Watch out, this solution you propose is broken! The possibility of deadlock is minimal, but this is even worse, as chances are you don't notice anything till it's too late and the app has been released. Counterexample:- A feeds the data.
- A checks
vI.size()!=0. This evaluates to true (B has not been given access by the system yet).
- Thread switch: B begins executing, process the whole data and sets
dwWait.
- Thread switch: A resets
dwWait and wait for completion --for ever.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi again,
Ok, here is my latest attempt to resolve this.
Handle mMutex;
mMutex = CreatMutex(...);
ThreadFunc()
{
while (1)
{
WORD wdCheck = WaitForSingleObject(dwRun, INFINITE);
switch (wdCheck)
{
case: 0
{
WaitForSingleObject(mMutex, INFINITE); // New code here.
for (int I = 0; I < vI.size(); ++I)
...
ReleaseMutex(mMutex); // New code here.
SetEvent(dwWait); // Now vector is empty send event.
}
case: 1
{
}
}
}
void Wait()
{
WaitForSingleObject(mMutex, INFINITE); //New code here.
if (vI.size() != 0)
{
ResetEvent(dwWait); // This will make sure to wait for event.
ReleaseMutex(mMutex); // New code here.
WaitForSingleObject(dwWait, INFINITE);
}
ReleaseMutex(mMutex); // New code here.
}
Wooweee, I think I got it right this time.
Again thanks for all of your help.
Ken
|
|
|
|
|
Is there a way to prevent a modal dialog from closing when a user initiates the WM_CLOSE?
I'm handling WM_CLOSE message using my own OnClose() where I display a message box with YESNOCANCEL. If the user selects CANCEL I want to return them to the current dialog, unharmed. I tried just returning before executing CDialog::OnClose(), but it still closes and ends the application.
I've read many suggestions within the forum and nothing seems to do what I want, all result in the dialog closing and app ending.
-kg
Ken Goguen
|
|
|
|
|
This is done Handling the WM_CLOSE..
void CTestDlg::OnClose()
{
if(MessageBox("Close?","Really?",MB_YESNOCANCEL)== IDYES)
{
CDialog::OnClose();
}
else
{
}
}
|
|
|
|
|
Like I said, that's what I am doing and it still closes...
void CMyDlg::OnClose()
{
if (curFileDirty) {
int answer=MessageBox( "Changes have been made. Would you like to Save them?", "Warning", MB_YESNOCANCEL | MB_ICONQUESTION );
if (answer==IDYES) {
if (currentPrjFilePath=="")
OnFileSaveAsConsolidation();
else
OnFileSaveConsolidation();
finalClose();
CDialog::OnClose();
}
if (answer==IDNO) {
finalClose();
CDialog::OnClose();
}
}
}
Ken Goguen
|
|
|
|
|
Ummm... Override also OnOK and OnCancel to do-nothing functions and see what happens.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You need to do what RobJones showed in handing your OnClose. Note in particular, do *NOT* call CDialog::OnClose if you don't want to close the dialog!
Also, you will probably have to override OnOK and OnCancel and do something simimlar there, if your dialog has OK and Cancel buttons.
Even a broken clock is right twice a day.
|
|
|
|
|
When I include a manifest (XML) file to use the Common Controls version 6 in the Resource or the path, and I call ::MessageBox(NULL, TEXT("Hello"), TEXT("Hello"), MB_OK), the messagebox isn't shown (I only hear a sound), if I do not include the manifest everything works fine.
It goes even wrong when I do:
#include "resource.h"
#include <tchar.h>
#include <windows.h>
int __stdcall
_tWinMain (HINSTANCE hInstance, HINSTANCE, TCHAR * lpCmdLine, int mainFrameDisplayMode)
{
MessageBox(NULL, TEXT("Hello"), TEXT("Hello"), MB_OK);
}
Sjoerd van Leent
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
This is most weird! Try adding the flag MB_ICONINFORMATION as well as MB_OK (Just a guess) .
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Tried it but it didn't work, it's even more weird, I looked at the sorce of MFC, and know I'm really totally confused, it's done the same way I do.
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
Do I need to register a manifest file or something, I really don't know whats going wrong.
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
Hi,
I have lots of pointers floating around in my application and it would be fun and also reduce the footprint of my app if I could save them temporarily to a file.
Need help.
Thanks
B.
|
|
|
|
|
If you were to save the pointers, you would have a load of numbers on disk, and unless you didn't delete the memory they point to, they would be useless. If you didn't delete the memory, you'd just have the tedious job of making sure you did at some point and pulling them from the file. It sounds like a bad idea to me.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Huh?
What do you mean ? that you have THAT many pointers that the memory is overflowing ? You want to save the pointers or the objects ?
I think you want to have "auto" serializing objects, that will unload part of them on disk, and load it back when the pointer is accessed again ? is that what you want ?
And you might save some memory, but the application would slow down!
Max.
|
|
|
|
|
Generally you cannot save out pointers unless you were to create your own heap manager, and that is a task unto itself.
What I would suggest to get the same effect that you are shooting for, is create a serializing function to store your objects to disk. All of the objects and strings that are shared through pointers should be stored in a table with an index or a handle ID. Then when you want to associate a the original pointer to the parent object, store the ID or index in the file instead.
Then when you reload the file, you will have recreate the objects in the tables, but you can store the IDs or indices in the tables. And when you recreate the objects that use the pointers, you look up the pointers in the tables that you created.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
The pointers really point to some house made objects which are generated from a serial flow of data and then "consumed" by the app.
The problem is that this app might be receiving data for a long time without consuming which, if not properly handled, might cause a memory blast.
The solution seems to be the serialization/deserialization of objects into/from temp files. It is better having a slow ill app than having a quick dead.
Thanks for the feedback.
Bunburry
|
|
|
|
|
how come the data is not processed right when it's received ? don't answer, just thinking out loud...
If your application is not speed dependant, I'd store the incoming data on disk right away, and only keep in memory the "file names", and when the data need to be processed, load it back from disk.
The problem with that, is that if the amount of data "received" in the house objects is really small compared to the overhead of having it on file; you'll still have the same memory problem.
Bunburry wrote:
It is better having a slow ill app than having a quick dead.
Well, it's better to have a healty running app than and slow and ill one!
Max.
|
|
|
|
|
Bunburry wrote:
The pointers really point to some house made objects which are generated from a serial flow of data and then "consumed" by the app.
I would use memory mapped files!
Store your data in a memory mapped file. That will allow you to access any part of the memory buffer as if it were a pointer (because it is loaded into memory), yet at the same time it is persisted to your harddrive. Therefore if you do not consume the data immediately it can be stored to disk.
The only issue here is that you will need to manage the memory in the file in such a way that will allow you to flag the ranges of memory that have and have not yet been consumed.
Bunburry wrote:
It is better having a slow ill app than having a quick dead.
Basically it is best to shoot for a healthy app. Once you get a basic design set forth that is healthy, you can always improve the speed later. The speed can come from eliminating processing that isnt necessary, or moving items to back ground threads and processes. Get your solution working first, then increase the speed later.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Besides all thoses problems, it's not possible to have a garbage-collector working with it.
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
You wont need a garbage collector, you will simply need a small class to manage the stream pointers for each of the data pieces. I have used a memory mapped file in a number of projects for interprocess communication where I managed data streams in both directions.
In this particular instance, the data would be copied to the memory mapped file, and if the data should be stored to disk, the virtual memory pages will just need to be flushed to the disk and it is instantaneously saved.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Paul Watt wrote:
You wont need a garbage collector, you will simply need a small class to manage the stream pointers for each of the data pieces. I have used a memory mapped file in a number of projects for interprocess communication where I managed data streams in both directions.
I didn't make my point clear enough, I meant if you're using a Garbage Collector, the pointers move around, if you save the pointer to a file, you must explicitly lock the pointer, if not, the ponter is read but doesn't point to the right address.
Sjoerd van Leent
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
