|
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
|
|
|
|
|
|
i have put a timer like Sleep (100),now it remain there ,but i problem havnot solve yet because it opening other console ,but i would like to do this in same window ,like other normal program
|
|
|
|
|
you are supposed to know such basic things yes.
|
|
|
|
|
Why are you even doing what you are doing? If you are writing a GUI program, use the GUI. If you want a console program, use the app wizard and create a console program. Don't mix the two!
(I prefer the printf family of functions.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Thanks ,i got this project in MFC and i have to use it as a console ,it will be very difficult to begin from new , getoff all the MFC part and remain works as same it will time taking .
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
