|
You can certainly use CreateProcess to create a new instance of your application, then quit your current process (the way you do this will depend on your application, for example, you might need to close your main window).
Service processes can be configured in the Services snap-in to automatically restart if the process crashes. See the ChangeServiceConfig2 API.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
i have a 24*7 highly database intensive mfc application. using cdatabase and crecordset objects.
it starts with 8mb and gradually increases to 34 mb (peak is shown as 60 mb)by task mgr, withing one day. Im sure of no memory leak. But sure windows is reserving (may be caching) the memory for my application, which is shown accross my application by task mgr.
is there any way to avoid this behaviour and make the application to take only that memory taken in the first couple of hours and not more.
So my question without any memory leak is this behaviour possible. any remedy to avoid this behaviour. like registery settings to avoid caching or something else...
|
|
|
|
|
The MFC database stuff will tend to cache rows if you don't use the right cursors.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
plz can any one guide me how to dump(apppend) the record(data) into excel sheet using Vc++(MFC wizard) and also to write program which controls data(i,e to delete data using a program ).
|
|
|
|
|
HI all,
supposed that my multithreaded program protects data with MFC CCriticalSection and it works fine on machine have one CPU. Is there any steps must I take to have the program worked on same platform with multi CPUs. Is this safe with CCriticalSection synchronization?
Many thanks,
Do Manh Hung
|
|
|
|
|
On a multi-CPU platform, the CPUs are given threads as required, and the second processor will take responsibility of the threads after a certain amount of load is placed on the first.
I believe that the threads given to one CPU are always handled by it. This means that the CPUs don't work together on a single thread, instead, both CPUs handle their own threads, and this thread-sharing is done by the OS.
Not sure, though.. However, the CCriticalSection object protects a resource or a piece of code for exclusive access for a single thread. As such, it shouldn't make a difference on what CPU is handling the thread at the given time: the thread from which the locking method is called is given an exclusive access to the forementioned resource, and the CPU just processes the thread. If another thread tries to access the resource, a violation is generated.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thank Keskinen,
As you pointed out, one CPU will handle given threads and "If another thread tries to access the resource, a violation is generated". Did you mean that when one CPU try to access another resource handled by other CPU, error will occur or it is not safe, for short?
Do Manh Hung
|
|
|
|
|
Unless the threads are affinitized using the SetThreadAffinityMask API, any thread can be scheduled to run on any CPU (if a mask is set, the thread can be scheduled on any CPU in its mask) at any point that it is ready to run. Windows tries to run threads on the same CPU they last ran on if possible, to exploit caching, but you can't rely on this - it won't hold up a thread that could run because its preferred CPU is not available.
Only one CPU can run a given thread at a time. A particular thread of instructions will never run in parallel with itself.
Also, Windows uses a pre-emptive scheduler - it can switch between threads in between any two CPU instructions, which means that some operations (for example, incrementing a variable's value) which require copying from memory into a register, modifying the value and writing back to memory can get interrupted before completing. If two threads try to increment a variable simultaneously, even on a single CPU system, you can get a situation where only one increment ends up being written back.
To prevent this, Windows provides synchronization objects and interlocked functions. The interlocked functions allow primitive values (usually a long) to be modified in a way that cannot be interrupted and forces any other CPU to wait before accessing that memory location - an atomic operation.
For more complex data structures, you need to use a synchronization object such as a critical section. For critical sections, only one thread can enter at a time. If the critical section is already taken by a thread, any other thread will block (cease executing and wait - the OS scheduler will not assign it to a CPU) until the owning thread releases the critical section. Some synchronization objects guarantee a particular order in which threads will be released, but the critical section is not one of them.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Yes, a critical section will work fine no matter how many CPUs you have.
However, be aware that if you do have any bugs where data isn't protected from simultaneous access, they will likely be hidden on a single-CPU machine. So it's always a good idea to test on a dual CPU machine to look for those kinds of bugs.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
I even hear the Windows "OMG I booted up fine" sound.
-- Paul Watson diagnosing hardware problems.
|
|
|
|
|
So it's always a good idea to test on a dual CPU machine to look for those kinds of bugs.
This can not be stressed enough. If someone writes a multithreaded application, they MUST have a dual CPU system to test it on.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
A critical section is equal to a semaphore, and a semaphore is an nt serializing instrument which does work no matter how many cpus u use. Every synch object has a kernel-mode structure which state is accessed by interlocked functions.
Don't try it, just do it! 
|
|
|
|
|
Thank all of you,
|
|
|
|
|
Hi all,
I'm writing an application which incorporates a number of tools. Each tool is hosted in a CDialog class. Is it possible for a CDialog class to appear in the Task Bar? It's quite annoying having to minimize all other windows to find it.
Mark
|
|
|
|
|
|
That was pretty easy 
Thanks
|
|
|
|
|
Im currently a computer science student, and I have been wondering if every member varible for a class has its own get/set functions in a real program. The c++ books we have been using have get/sets for most private members, and the java books have get/sets for everything. I have just been noticing that most of the classes i write are mostly get/sets for the private varibles. Am i doing this wrong or ?
Any suggestions would be great.
-x
|
|
|
|
|
Well, at the company I work with, every member must be private and therefore requires get/set methods. I think you'll find that's a fairly common standard.
As for a right or wrong... Develop a standard and stick to it. There is really nothing wrong with one way or the other, as long as you're consistent. Obviously, if your professor requires it to be done one way, then do it that way.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanks a lot sir. Just wanted to be certain it happen in the real world. =)
|
|
|
|
|
|
Wll very first thing is if you want to access private members you have to write get/set function, if you do not want to access the variables we shouldnt write. Just read "Thinking in c++" by Bruce Eckel and "Effective C++" by Scott meyer for thorough understanding and dont mind to surf the followinf site
http://cplus.about.com/library/blcplustut.htm?PM=ss12_cplus
regards
Balkrishna Talele
"Every question has good meaning"
|
|
|
|
|
Thanks a ton, I will check those out and read that site.
-x
|
|
|
|
|
Generally i don't use/see a get/set for each member, let alone make them all private/protected.
Iff a member state is 'linked' to another member state then they will both be private or protected and a get/set will be created for each in order to enforce the state relationship.
But having this :
class Foo {
private:
int x;
public:
int GetX ( void ) const { return(x); }
bool SetX ( int X ) { x = X; return(true); }
);
Adds nothing, and make things more complex than need be (in my opinion).
We are thinking developers, not blind pattern slaves ... or so the theory goes.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I don't think this is smart idea to make ALL members private and make get/set methods for them. It will make classes and their usage too big and inefficient. But this depends on class type.
Even in MFC you'll find some classes with public members, like CRect (top, left...), CWnd (m_hwnd), ....
rrrado
|
|
|
|
|
rrrado wrote:
It will make classes and their usage too big and inefficient.
You haven't measured this assertion. Firstly, the use of a get or set accessor method, if all it does is set or get the private variable, amounts to a very few instructions - very few more than would have been used if the variable was set directly. If the accessor method is marked inline and the optimiser decides to in-line it, the actual code generated is typically identical to setting the variable directly.
If not inline, the runtime cost is typically negligible - the processor can predict that the branch is always taken and fill the instruction cache directly. There's a small cost in code size which could potentially lead to more paging activity, but this is likely to be minor. The overall cost of your data structures typically dwarfs the cost of minor issues such as this. If your code profiler tool indicates that this is causing a problem, by all means remove the accessors. But not until then.
In terms of data size, there is no difference. If you make the accessors virtual, you will increase the size of the virtual function table (and if these are the only virtual members, the size of the object by one pointer). Simple accessors are very rarely made virtual.
It's far easier to change the code to bypass accessor functions, i.e. make a previously-private field public, later on than it is to introduce accessors. It's better to keep your data private to keep your clients' hands off it - to prevent accidental alteration and to preserve your contract - a concept known as information hiding. If you wanted to calculate a data value rather than to store a cached version, and you've used accessors, you can simply change the function body; you'll need to do a lot more work if you made it a public member.
The MFC classes you mention are simple wrappers which tend not to have problems with synchronising the values of different members of the class. CRect's whole identity is based on the four data members top, left, bottom and right. CWnd already has abstraction behind the m_hwnd member - it's a handle to the underlying window object, which Windows never allows direct access to.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
hey I am trying to build a DLL in pure C/C++ !!
I want to share the variable values accross multiple processes.
I am a novice and want to learn how to do it..
please help me..
thanx in advance..
Pritpal
Pritpal
< coder in evolution >
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
