|
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 >
|
|
|
|
|
Well, Whenever you build a dll and if any exe is loading your dll, it will run in its own process,so no question arises that ur variables wil be shared. If you make a SINGLETON, you must build an ATL Server exe(which will be out process) and then you can share variable. But as you say you are novice, it will be little difficult to write the singleton in ATL.
regards
Balkrishna Talele
|
|
|
|
|
No
It is possible to share data/variables among processes in regular DLLs. We can use #pragma data_seg("SHARED") to declare shared data segments. A very good article is there in CP - http://www.codeproject.com/dll/data_seg_share.asp
rgds ...mil10
|
|
|
|
|
I'd recommend looking into memory-mapped files. The shared-segment previously mentioned doesn't work if the dll can't be mapped into the correct address space due to dll relocation. In other words, if a dll is already mapped to the address it needs to be shared, then it doesn't work right.
I believe there are articles that describe how memory-mapped files work on this site. If not, I can give you an example.
--
Joel Lucsy
|
|
|
|
|
Howdy,
I have a dialog with a CStatic positioned on it. The top left point is at the right placement. How would I maximise the CStatic so that it fits neatly on the screen width
and height (to bottom of screen) but not changing the top left point? Can't quite get it right.
Thanks,
|
|
|
|
|
Get the windowpointer of the CStatic control and use SetWindowPos to resize it in OnSize Eventof the dialog.
|
|
|
|
|
m_pView is defined in CMyDialog dirived from CDialog ,
private CView*m_pView;
in modeless dialog, for example CMyDialog::CMyDialog(CView*pView)
{
m_pView=pView;
}
i think using CView as the argument to allow CMyDialog to use with any other CView Class,how about you?
|
|
|
|
|
Most of the time we get such stuff null, onr foolproof method is to have the variable static
OR
2) The pointer is pointing to what , when the object is getting constructed, it will assign the default values which are in CViews constructor... You need to write copy constructor
regards
Balkrishna Talele
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
