 |
|
 |
can u explain how to use progress bar here while the thread is running
|
|
|
|
 |
|
 |
although not very complex, still very usefull! Didn't think of this.
|
|
|
|
 |
|
 |
hi, i want to make an application with two or more thread, that start at a precision time.
e.g.: a start the application (process) at 12:00 and all the threads start at 12:30.
how can i do that?
|
|
|
|
 |
|
 |
Hello..Thank you very much. Your code did solve my problem, but Since I am using this in a while loop, Every time I create a new Thread after the fucntion is executed, I need to terminate the earlier thread before the next Thread gets created. I do not want too many Threads Just hanging on after their intended use. Is there a way to identify a particular Thread?
Kind regards,
Mafaz
|
|
|
|
 |
|
 |
Based on some of my experience in real-time multithreading, when looping (due to waiting to complete like a goto or Join() there is a potential problem: the loop will cost the CPU a lot of resources (up tp 100%), just doing nothing, diminishing the power of the Threaded processes.
This is specially noticeable when the involved processes are lengthy (several seconds of process, like I/O by sending a SMTP mail), not in this sample, which accomplishes in a few microseconds.
So I suggest anyone who wants preserve CPU power to insert a small Thread.Sleep(1) in this 'wait' loops, and the thing will run flawlwessy w/o usage of CPU.
Also notice the tremendous LAG the .NET system has to start the threads, it may take up to 1-2 seconds each (no predictions) and take care not to fire too much Threads out of the system pool, so it may starve and hang the system until another Thread ends it's current process and is ready to be recycled inside the .net runtime framework.
regards from Argentina
PandoraBox
|
|
|
|
 |
|
 |
Good suggestion. I've changed the code. Thanks.
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
 |
Here's a bookmark for you:
Threading in C#[^] It's a free e-book that's been available for several months.
Your code basically does two "novel" things:
1. Starts a thread with more than 1 parameter.
2. Waits for the completion of all of the threads.
You'll notice the link I provided scrolls down the first section about halfway. In that section he covers point #1, so it's not incredibly novel.
#2 is also a failure. If you fire up multiple threads, you're typically going to do one of two things:
A. wait until they all finish
B. activate other processes as each thread finishes
If you're doing A, then your code fails here. Call the .Join() function for each thread and you're done. You're not going to anything until all of the threads are done, so it doesn't really matter which one you're waiting on.
If you're doing B... well you're not doing B, which is OK, b/c that's a whole different problem.
|
|
|
|
 |
|
 |
Thanks for the eBook link and it has got great contents. I respect the author. My article is just a step by step illustration for: how to send multiple parameters to a thread. In my opinion, it is one of many refreshing ideas out there.
I disagree to use a Join() as it would only allow threads to execute one after another.
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
 |
Pasupathi Narayanan wrote: I disagree to use a Join() as it would only allow threads to execute one after another.
You said this earlier. It is still not true.
Thread thread1 = GetThread1();
Thread thread2 = GetThread2();
// at this point, neither thread is running
thread1.Start();
// now thread1 is running and thread2 is not
thread2.Start();
// at this point, both threads are running
thread1.Join();
// now thread1 is done running and thread2 may or may not be running
thread2.Join();
// now both thread1 and thread2 are done
Does that not address your concern with Join?
|
|
|
|
 |
|
 |
Thanks Max, beat me to it.
Pasupathi, the above quoted statement demonstrates very clearly that you do not understand threading in a very fundamental way.
That's OK, threading is a very complicated problem and the MSDN documentation does not do it any justice. Please read the e-book link in full and run some of the examples and hopefully you will come to understand multi-threading (and see why your previous statement was patently false).
|
|
|
|
 |
|
 |
I am not a 'threading' guru though I have a fundamental knowledge about it. I think i can demonstrate using that...
Basically, Join method tells the runtime to block the calling thread until a thread (worker) is terminated. Therefore, the Join method is essential in situations espicially data sychronization is needed between multiple threads including the calling thread.
Let me argue with Max's idea. What would possibly happen with his idea with the realtime execution? The runtime will put the main thread (calling) into a dead queue which is not at all considered for further execution by processor. However, the runtime has to keep an eye on the main thread pointer as it has to be called back to the normal wait queue for the processor to pick it up, once Thread1 completes its job. How much time the runtime needs to monitor? I would say it is: little unknown. May be 'n' amount of time where 'n' is incremental until Thread1 completes. The main thread would gift the runtime, kind of busy wait... Why? All because of using the Join method. The same would apparently happen again with Thread2 as well. As a conclusion, the runtime- in our case is instructed to emphasize a priority with these threads such as Thread1 to complete first and then Thread2 then finally the Main thread. (May be you and Max need to re-consider my statement this case).
Now let us look into the other way of doing this using Thread.Sleep(1). This way, the execution is blocked for a stipulated number of time I.e. one Millesecond. It is an explicit wait. Like, throwing a ball against a wall where you know that the ball will return back for sure and no one should exist in the other end to return it. Conceptually thinking, there is no additional overhead to monitor the main thread. (Of course i am doing this in a loop and it is true this is not a kind of 'best of all' approach)
In my opinion, if there is no essential way to do so, we can fall back to use Join method.
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
 |
As a conclusion, the runtime- in our case is instructed to emphasize a priority with these threads such as Thread1 to complete first and then Thread2 then finally the Main thread.
This isn't what's happening. In Max's example you could have done:
thread1.Join();
thread2.Join();
OR
thread2.Join();
thread1.Join();
With the same result. There is no "prioritizing" here. In both cases you have to wait for everything to finish. Just b/c I'm waiting on thread1 doesn't mean thread2 isn't processing. If I Join() a thread that's already done, then I'm not going to incur more overhead.
In any reasonable threading example, the threads will have long running processes. In your method you interrupt yourself every 1 ms, cutting off the very processor time that you're trying to use. In the Join() method, you just let the processors do their thing and they'll let you know when they're done. Why complicate the situation, do you think that by bugging the processor every millisecond you'll get results quicker?
Really, the Join() method is the fundamental way to solve the problem of running a static number of threads and waiting for all of them to finish. Your method "works" but would cause serious complications in non-trivial code (like how many milliseconds do you sleep?)
|
|
|
|
 |
|
 |
There is nothing that can be done with a goto that both (1) should be done and (2) cannot be done with another flow control structure.
|
|
|
|
 |
|
 |
I think the event based 'notice' what Yuck was saying -will be a good replace for the goto.
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
 |
Even a while loop would do the trick. Don't get me wrong: I agree with "Yuck," but I'm more focused on the "goto" than the spinning.
The goto has got to go.
|
|
|
|
 |
|
 |
Cool. I've changed the code a little.
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
 |
There's still a goto in the code that I see.
|
|
|
|
 |
|
 |
Performing a busy wait using goto while you wait for the threads to finish is Really Bad Style©!
Ever heard about Thread.Join() or ManualResetEvent?
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
 |
|
 |
I totally agree with your comment on the usage of goto. Yes, it is bad practice however, the above scinario does not have any things to do after raising the threads. So, it does not leave many options.
About using Thread.Join() method, I think this would lead the thread execution to he processed one by one in a sequential manner rather simultaneous. Therefore, we slip the concept of multi threading if .Join() method is used here. I dont always prefer to use this unless there is a specific reason to do so.
ManualResetEvent is a real good option. I also feel it does not provide details about the thread execution is complete rather it signals a state that the thread initiation is started and ready to execute. What do you say?
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
 |
Well, after starting the threads you just want to wait until both have finished.
In your CatchValue: if(... line you test whether the MulThread has finished and (only if this thread has finished, the compiler doesn't evaluate the second part if the first part evaluates to false already) if the AddThread has finished as well.
So the two linesMulThread.Join();
AddThread.Join(); are 100% equivalent to this whole horrible goto construction.
In addition, in many cases you don't have this kind of synchronization (start many threads and wait for all to finish before accessing the common results). I think most of the time you either start a separate thread to perform some work without being interested in any results or you are interested in the results when they are available, i.e. you want an event to be fired by the thread telling your main thread that the worker thread has finished and that now the results are available.
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
 |
|
 |
I would agree on raising an event to tell the main thread that the worker thread has done the job.
Cheers,
Pasupathi Narayanan
|
|
|
|
 |
|
|
 |