 |
|
 |
I just have some critiques
1. WaitForSingleObject isn't the end of the world. The overhead to enter the kernel is not 500 years long! Unless this was an extremely time critical operation I wouldn't have worried about "switching into the kernel". The overhead isn't in the switch it's in the fact that certain kernel operations can trigger a context switch before your quantum was really up, and waiting for an object is one. So, I would actually re-consider WaitForSingleObject (Since you used 0 that time switch technically shouldn't happen, but you'd need to debug and see if it would in any case your thread would still be added right back to the ready list anyway) unless you were doing something that really could be considered real time, otherwise the overhead probably wouldn't have been noticed. Did you do any benchmarks to determine if a WaitForSingleObject implementation was worse?
2. Why do you need to time out if you don't get the lock? Does this mean what you were going to do wasn't that important anyway? If so, why not create a single thread that does all the work and then just remove all the locks? I would check your design if a thread that needs a lock doesn't really need it. What are you attempting to accomplish by doing this?
|
|
|
|
 |
|
 |
A problem with this for example is that if you want your thread to do something, it then attempts to perform this operation. It fails since it can't grab the lock so it does something else. Then it comes back again to do that same thing, it still can't grab the lock because it can never get there at a time when someone else does not have it.
If you want to implement something that's time critical like that to a resource you really need to make sure the lock code is very small and locks are never held long. Another implementation that could be done is scheduling. You register for notification when the object becomes avaialble and you get a notification or callback when this occurs. This would help to minimize locking for example.
|
|
|
|
 |
|
 |
Hi
Is there any chance for a user thread created from a parent GUI application to be affected by the threads running in kernel/user modes in the system. Please clarify and if the answer is "YES", please get me a solution to this.
Regards
Sreekanth Muralidharan
Hyderabad
|
|
|
|
 |
|
 |
You will need to clairify your question I am not sure that I understand what you are talking about.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
 |
|
 |
Hi Tony
See.I have created a worker thread in my application. I am doing some USB processing in the thread. While I am doing that, if I try to minimize any of the windows in my desktop, the thread gets disturbed and the data handled by the thread loses its integrity. Since the thread is just a worker thread, there is no question of messages interacting with it, if I am not wrong.
Actually the operations I am doing in the thread relates to reading from and writing to the USB port.
Please revert with your invaluable suggestions.
Sreekanth Muralidharan,
Corporate Systems Consultant [Embedded Systems],
INDIA
|
|
|
|
 |
|
 |
This sounds more like a scheduling issue as when you minimize that application you just added it's GUI thread (and possibly others) to the READY List. The READY list is just the list of threads that are now ready to be run and the scheduler will simply walk through them. If your thread makes any calls into the kernel, certain APIs will cause a context switch to another thread. Interrupts that occur on the system, such as when you move your mouse or type will also cause an interruption on the current thread, which again may lead to a possible context switch as with most things, the scheduler is generally consulted on certain operations.
Windows does not differentiate between user and kernel threads, so a user mode thread could be given a higher priority so that it would be less likely to be interrupted or not interrupted at all.
; PUSH REALTIME_PRIORITY_CLASS
PUSH HIGH_PRIORITY_CLASS
PUSH EAX
CALL SetPriorityClass
CALL GetCurrentThread
; PUSH THREAD_PRIORITY_TIME_CRITICAL
PUSH THREAD_PRIORITY_ABOVE_NORMAL
PUSH EAX
CALL SetThreadPriority
"Real Time" will make it impossible to interrupt your thread BTW. What you may want to consider is that you boost your thread priority while you are doing time critical work and when you are done you again lower your thread priority below normal. This is one way to help a user mode thread not become interrupted at all.
This is just a high level view of what could be the possible problem. You could get out the kernel debugger and do some debugging though and attempt to find out what is going on with the thread. Perhaps another thread started hogging your time or its simply the fact that when you did the mouse click to minimize the application, that set off a series of events and context switches that just interrupted your thread. BTW, if you do set the thread to high priority and it takes a long time the system will either look hung or run sluggish.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
 |
|
 |
Hi Tony
Thanks a lot for finding time in analyzing my problem. But in fact, I am creating the thread with a real-time priority which I believe is the highest priority I can set to a thread. I did this while creating the thread with a flag set in AfxBeginThread call. Still, this did not solve the problem. Is there any way to increase the priority of a thread? I could not understand ths part in your last message:
Toby Opferman wrote:
; PUSH REALTIME_PRIORITY_CLASS
PUSH HIGH_PRIORITY_CLASS
PUSH EAX
CALL SetPriorityClass
CALL GetCurrentThread
; PUSH THREAD_PRIORITY_TIME_CRITICAL
PUSH THREAD_PRIORITY_ABOVE_NORMAL
PUSH EAX
CALL SetThreadPriority
Bye..
Regards
Sreekanth Muralidharan,
Corporate Systems Consultant [Embedded Systems],
INDIA
|
|
|
|
 |
|
 |
That is actually the assembly implementation of how to manually set the thread priority.
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS ); SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_ABOVE_NORMAL);
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
 |
|
 |
....Hi Tony....
Thank yoooo !!
Byieeee.
Regards
Sreekanth Muralidharan,
Corporate Systems Consultant [Embedded Systems],
INDIA
|
|
|
|
 |
|
 |
I was just wondering, why didn't you use EnterCriticalSection instead? I believe it's available on Win 9x platforms (correct me if i'm wrong).
Actually, I'm also curious whether there's a significant performance difference between TryEnterCriticalSection and EnterCriticalSection...
Thanks!
|
|
|
|
 |
|
 |
That's a good question. He wants to know if the lock is already held. If it was, then fail to get the lock and do something else. My question, why the hell would you do that? Is what you were doing not that important? If not then I guess you might as well not do it at all then! Then you don't have to implement any locking!
|
|
|
|
 |
|
|
 |
|
 |
Thanks for the links Neville!
I did look into Metered Sections, and since this was primarily developed for IPC (I didn't need IPC), and since this "drops" to a kernel object if there is a contention, I decided this didn't meet my needs. Metered Sections are great, but they're fast only if there is no contention. They're also far too fatty if you don't care about protection amoung seperate processes.
For protection within a single process, CTryEnterCS is 100% user mode and very, very small.
Thanks again!
-OP Barnes
|
|
|
|
 |
|
 |
hey dude
u think u can help me multithread this article?.i can't seem to get pasted the deadlock that seems to be occuring in the memory allocation function "new";
Thanks a bundle.
It's a sh*tty world. Take advantage of whomever,whenever,whereever. And oh.. becarefull what you say to me,am too sensitive.Or i might just show up at your house.i retract the latter,am trying to be a better person.
|
|
|
|
 |
|
 |
If you can provide some specific information on what you are doing and where it is going wrong I can try and help. There certainly shouldn't be any deadlock occur in new, assuming you using the multithreaded version of the MFC & CRT libraries. Best just to post questions in the C++ message board.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
 |
|
 |
It may works incorrect when varous threads have different priority. Details described by J. Richter.
SeRya
|
|
|
|
 |