|
it dosn't mean add (=) just in the sense of is this the write way to add the code to the rest of the code?
|
|
|
|
|
if 'x' is actually '*', then it looks correct, provided dReg and aReg are what they appear to be.
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,
I have an object which is purely a data structure which is shared between several threads. At present, I control access using a mutex which I grab when I need to use the data object. The problem is I have already found places where I have missed the WaitForSingleObject() to lock the data so I am considering making all data members private and using Get/Set members which will automatically grab and release the mutex.
My concern is what will be the impact on performance? At present, I only need to lock the mutex once before accessing all data members, then release the mutex.
To put some figures on things, the program runs a timer thread at a rate of 10Hz, three or four other threads need to access the data object at rates between 10Hz and 1Hz and there are 8 doubles in the data class.
I am really looking for opinions on whether there will be an appreciable performance hit from making it totally threadsafe.
Thanks
Tony 
|
|
|
|
|
softwaremonkey wrote: shared between several threads
softwaremonkey wrote: using a mutex
I think you'll find critical section[^]s have better performance, as they're not kernel objects (they're no good between processes, unlike mutexes). Alternatively, if you're targetting Vista or newer, a slim reader/writer lock[^]?
softwaremonkey wrote: At present, I only need to lock the mutex once before accessing all data members, then release the mutex
I believe that if a thread has ownership of a critical section, it can request ownership again and it gets it without delay.
So, you could have something like:
struct S
{
S() { InitializeCriticalSection(&myDataLock); }
~S() { DeleteCriticalSection(&myDataLock); }
void Lock() { EnterCriticalSection(&myDataLock); }
void Unlock() { LeaveCriticalSection(&myDataLock); }
int GetData() { Lock(); int i(data_); Unlock(); return i }
void SetData(int i) { Lock(); data_ = i; Unlock(); }
private:
S(S const&);
S& operator=(S const&);
CRITICAL_SECTION myDataLock;
int data_;
};
I'd be tempted to use RAII[^] to lock and unlock, but that's a detail...
Anyway - you could then use the accessor OR surround accesses with Lock/Unlock calls?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi,
Thanks for the reply. Thats a neat solution.
Stuart Dootson wrote: I believe that if a thread has ownership of a critical section, it can request ownership again and it gets it without delay
This is true, but if we call lock() and unlock() within the Get/Set methods then we reliquish ownership so if I need to call Get/Set for each member, I think we still have the overhead of entering and leaving the critical section.
I am no expert on this subject but dont critical section only prevent multiple threads calling the same pielce of code at the same time? If thats the case, wont we still have problems if one thread is calling Get() while another thread is calling Set()? 
Tony
|
|
|
|
|
softwaremonkey wrote: This is true, but if we call lock() and unlock() within the Get/Set methods then we reliquish ownership
No - the critical section retains an ownership count for the current thread, so you need to unlock as many times as you locked. So, if you did:
S s;
s.Lock();
s.SetData(1234);
s.Unlock();
s is locked throughout.
[edit]PS - I should emphasise that I'm pretty sure that's how critical sections work - I'd validate that belief before relying on it!!![/edit]
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks,
I have implemented your suggestion and it all appears to be working great.
What a great feeling it was to delete all those WaitForSingleObject() calls in my code 
I will now leave it running for a few weeks to make sure everything is OK.
Thanks for your help 
|
|
|
|
|
Stuart Dootson wrote: I should emphasise that I'm pretty sure that's how critical sections work
Yes that is how they work.
Stuart Dootson wrote: I'd validate that belief before relying on it
Absofreakinlutly!! Of course fraking microsoft keeps hiding that information in the documentation[^] 
When a thread owns a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. To release its ownership, the thread must call LeaveCriticalSection one time for each time that it entered the critical section. There is no guarantee about the order in which waiting threads will acquire ownership of the critical section.
|
|
|
|
|
led mike wrote: Absofreakinlutly!! Of course fraking microsoft keeps hiding that information in the documentation[^]
I only point to the documentation - I don't bother reading it 
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Even if that were true it would still put you one step ahead of most of these twittering monkeys. ![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)
|
|
|
|
|
I am not convinced it makes sense to protect data at the field level.
assuming not all combinations of valid values are valid for the overall object, having protection at the member level can still yield an invalid object state (one thread changing one member, then another thread changing another member)...
|
|
|
|
|
Im not sure that this is a problem. As I understand it, if one thread enters the critical section, it will prevent any other threads from doing the same, even if the second thread is trying to access a different data member. This is because all Get/Set methods use the same critical section.
I could be wrong though. 
|
|
|
|
|
Luc's point is probably that if you want to change multiple values like a transaction, you'll need to embrace the "transaction" with a lock. Otherwise the calling the calling thread may be preempted and another thread may corrupt the "transaction".
It means that in this case it's useless to acquire a lock when entering a getter/setter method and release it when exiting.
On the other hand, if you don't have to change values like a transaction, you'll most likely do fine with the idea Stuart provided.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Right.
|
|
|
|
|
HEY EVERYBODY
I HAVE A PROJECT BUILT IN MFC AND NOW I WANT TO PRINT SOMETHING IN CONSOLE INSTEAD OF USED THE WINDOWS.
I HAVE TRIED FOLLOWING CODE BUT NOT WORKING ,,,,,GIVE ERROR........
BOOL CMANDTUApp::InitInstance()
{
AfxEnableControlContainer();
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
AllocConsole( );
// setup stdout
{
int fd = _open_osfhandle( (long)GetStdHandle( STD_OUTPUT_HANDLE ), 0);
FILE* fp = _fdopen( fd, "w" );
*stdout = *fp;
setvbuf( stdout, NULL, _IONBF, 0 );
}
// setup stdin
{
int fd = _open_osfhandle( (long)GetStdHandle( STD_INPUT_HANDLE ), 0);
FILE* fp = _fdopen( fd, "r" );
*stdin = *fp;
setvbuf( stdin, NULL, _IONBF, 0 );
}
// test stdin & stdout
//std::cout << "Console in place. Type a number: ";
/*
int x = 0;
std::cin >> x;
std::cout << "Value read: " << x << std::endl;
// generated code
*/
FreeConsole();
return FALSE;
}
WELCOME ANY TYPE OF ADVICES ,THANKS IN ADVANCE :
|
|
|
|
|
Are we supposed to guess what the error is?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
C:\MANDTU\MANDTU.cpp(91) : error C2653: 'std' : is not a class or namespace name
Error executing cl.exe.
|
|
|
|
|
yes i have added iostream above ,after
#include "stdafx.h"
|
|
|
|
|
Have you tried using printf() instead of cout? Have you seen this?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
ya thanks
NOW ITS NOT GIVING ERROR
BUT THE CONSOLE NOT REMAIN ,IT WIL ESCAPE SHORT
|
|
|
|
|
johnjitu wrote: IT WIL ESCAPE SHORT
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
MEANS IT CONSOLE SCREEN IS REMAIN THERE ,IT IS FLICKING ,MEANS I CANNOT SEE THE OUTPUT ,SCREEN WILL DISAPPEAR SHORTLY.
|
|
|
|
|
end your program with a readline or a read or something to that effect, then the console remains visible until you hit the enter key.
|
|
|
|
|
Thank you very much to all .........
|
|
|
|
|
So wouldn't it be easier to just create an actual console application, or do you really need a GUI for other reasons?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
