|
In that particular case it doesn't make any sense. But sometimes, when you have a function with multiple 'paths' and some of them call Function1(), then you would like to still lock the full function. But I agree, it is a bit messy...
|
|
|
|
|
In the case of Mutex, Multiple Lock will not be a problem, but Mutiple unlock creates some problem. The first mutexunlock ( I guess mutexunlock is internally calling ReleaseMutex() ) will release the mutex and so the rest of the code will not be having any effect of the mutex.
|
|
|
|
|
Naveen wrote: The first mutexunlock ( I guess mutexunlock is internally calling ReleaseMutex()) will release the mutex
No, this is not correct. From MSDN[^]:
After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call ReleaseMutex once for each time that the mutex satisfied the conditions of a wait function.
|
|
|
|
|
Ho ho..
I didn’t know that. Thanks for correcting
|
|
|
|
|
I think its specifically for wait functions called inside a thread . But the code I am listing does not contain any wait functions . There is a second lock/unlock when there is an access to a global variable .
Cedric
I think Naveen's point that the first call to mutexunlock will unlock the mutex object and the rest of the call to Function1() will not be threadsafe . What do you say ?
I am taking an important decision to affect many critical functions which have these occurances..
redindian
|
|
|
|
|
Read the link I provided: there's no such thing as lockmutex and unlock mutex in the Win32 API but it is a WaitForSingleObject and a ReleaseMutex instead. The wait function will have the same effect as a lockmutex when the mutex becomes available.
I don't know how you implemented the lock and unlockmutex functions but they should normally follow those rules.
|
|
|
|
|
During a function call DoEvents is not fired from a timmer, but I want to redraw / refresh the UI during the function call. pls advice
|
|
|
|
|
DoEvents? Do I smell VB?
Steve
|
|
|
|
|
No C++
void DoEvents()
{
MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0, 0, PM_NOREMOVE))
{
if(::GetMessage(&oMSG, NULL, 0, 0))
{
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
else
{
break;
}
Sleep(100); // Try to minimize CPU usage
}
}
|
|
|
|
|
What is the problem exactly ? Just call this DoEvent function in your lenghty function whenever you want to refresh your UI. I would remove the Sleep, because it is not really needed.
Anyway, I think it would have been a bit easier if you would have used a thread.
|
|
|
|
|
Thanks for responce. This DoEvent call itself is from thread
since the UI is almost frized, I am using waitableTimmer from a thread to update the progress bar, it is fine,but if I min & Maximize; the window, progress bar is ok but UI(App main window , Dlg box) in not refreshed/redrawn untill the currentl lengthy operation is done. Can not put the length process in thread. Any wise advice pls
|
|
|
|
|
ptr_Electron wrote: Can not put the length process in thread.
Why is this not possible can you explain??
Regards,
Sandip.
|
|
|
|
|
No no, Techinical possible, but not as per the req, if I need to do that much of the code required changes.
|
|
|
|
|
You have a primary thread that handles the UI and keeps it responsive. You have a secondary thread that does some work. During that work in the secondary thread, simply post a message to the primary thread telling it of the progress. This way, both threads can do what they're designed to do without worrying about the other.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Why the Sleep nonsense? Something like this looks more civilised:
void DoEvents()
{
MSG m;
while (::PeekMessage(&m, NULL, 0, 0, PM_REMOVE))
{
::TranslateMessage(&m);
::DispatchMessage(&m);
}
}
Steve
|
|
|
|
|
Did that but even then no luck
|
|
|
|
|
I didn't say it would fix your problem; I was just pointing that the Sleep is extremely poor programming and is not needed.
Steve
|
|
|
|
|
ptr_Electron wrote: Sleep(100); // Try to minimize CPU usage
Remove this. It serves no purpose.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Yes I removed sleep. I am using waitableTimmer to keep the UI active, during a very length call. Progress bar is working fine, but UI is Frised pls suggest me some good idea for this,
HANDLE timer = CreateWaitableTimer(0,false,0);
LARGE_INTEGER li;
const int unitsPerSecond=10*1000*1000;
li.QuadPart=-(2*unitsPerSecond);
SetWaitableTimer(timer,&li,350,0,0,false);
_beginthreadex(0,0,TF,(void*) timer,0,0);
unsigned __stdcall TF(void* arg)
{
HANDLE timer=(HANDLE) arg;
while (1)
{
if(iStoped==0)
return 0;
WaitForSingleObject(timer,INFINITE);
prgBar->StepIt();
DoEvents();
}
_endthread();
return 0;
}
void DoEvents()
{
MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0, 0, PM_NOREMOVE))
{
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
}
|
|
|
|
|
By using a secondary thread to do the work, your DoEvents() function is not needed. You have to stop thinking of 16-bit Windows.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hi,
Just needed a little guidance. Am creating a drive imaging utility mostly to understand the working. Can anyone guide me to a tutorial/example to make images of HDD on windows/linux using C/C++. Just the right direction will suffice. I tried googling it but all i get are the softwares to create the images not the actually approach to the problems.
thanks.
|
|
|
|
|
In linux, it is easy, just open the proper device. A raw harddisk is represented by say /dev/hda where as the partitions are represented by /dev/hda1, /dev/hda2, etc. Just open the file with fopen and use fread to read the data.
In WinNT (to include subsequent versions such as XP, etc) you can actually open device files the same way, but it is a lot messier. The NT kernel creates pseudo files like linux, but they are not as neatly grouped. They look like \\.\Volume{46b98f60-4a74-11dc-9364-806d6172696f}\ but have simpler aliases like \\?\Device\HarddiskVolume2
There is a open source program called rawwrite dd for windows that does just what you require and maybe you can glean some information from the authors homepage or from the source code:
http://uranus.it.swin.edu.au/~jn/linux/rawwrite-old.htm[^]
|
|
|
|
|
Thanks ...
|
|
|
|
|
Hi!
i want an article about .net exe files.
i want inject my code in this files (.net). how do i do?
i can inject my code in win32 PE files, but for .net exe file ???
please help me
Zo.Naderi-Iran
|
|
|
|
|
A .net exe is also a PE file.
Steve
|
|
|
|