|
Hi Christian,
I think in this way, my thread will be forever blocked until the signal is set, right? But my purpose is to do some work at 1 second interval and checks for stop at the same interval -- if the stop signal is not coming, other than blocking forever, I want the thread to continue to do its work.
Any comments?
regards,
George
|
|
|
|
|
Well, then you're on the right track with a timer.
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks Christian,
1.
Do you mean using Timer to check stop status or to do the regular work?
2.
If you mean using Timer to do the regular work, I think the Timer class is used to perform a task in a regular interval no matter whether or not the previous task is completed or not. So, it is possible to execute two tasks at the same time if the 1st task is not completed in 1 second for some reason. Right?
How to avoid such situation?
regards,
George
|
|
|
|
|
1 - if you want to execute code regularly, use a timer
2 - Your timer is not going to fire again if that thread is busy. So, it's not going to run your code twice at the same time, it's single threaded. If your code takes 30 seconds to run and you have a 20 second timer, the timer will just fire late.
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks Christian,
You mean using timer and in the timer execution method, we do two work items -- checks both the stop status and do the regular work?
regards,
George
|
|
|
|
|
Yeah, I guess so.
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks Christian,
The timer solution works. A further question, what are the pros and cons compared with using sleep and using timer from functional and performance perspective?
regards,
George
|
|
|
|
|
Christian Graus wrote: it's not going to run your code twice at the same time
I find that not to be the case (with a System.Timers.Timer anyway, other Timers may differ).
private System.Timers.Timer tt = new System.Timers.Timer ( 1000 ) ;
public Template
(
)
{
tt.Elapsed += F ;
tt.Start() ;
return ;
}
private void
F
(
object sender
,
System.Timers.ElapsedEventArgs e
)
{
System.Console.WriteLine ( "Start" ) ;
System.Threading.Thread.Sleep ( 5000 ) ;
System.Console.WriteLine ( "Stop" ) ;
return ;
}
Sample output:
Start
Start
Start
Start
Start
Stop
Start
Stop
Start
Start
Stop
Start
Stop
Stop
Start
Stop
Start
Stop
Start
Stop
Start
Stop
Start
|
|
|
|
|
George_George wrote: I think the Timer class is used to perform a task in a regular interval no matter whether or not the previous task is completed or not. So, it is possible to execute two tasks at the same time if the 1st task is not completed in 1 second for some reason. Right?
AFAIK, timer's execution will be blocked until it finishes the job. So you won't be able to run two tasks in parallel in normal case. I think you can use a Producer/Consumer Queue[^] like things to do this. Each time timer ticks, enqueue job. So it will be executed on another thread and timer thread won't be blocked. I might be wrong here
|
|
|
|
|
Hi N a v a n e e t h,
It is really a great article. I read the sample you mentioned, I like the code but confused about what means "except that the caller doesn't get blocked if the worker's already busy with a task", any ideas?
I think the caller (I think in this sample should be someone which enqueues the task) is blocked when the worker is working since it uses a lock called "locker" when Enqueue. Any ideas?
regards,
George
|
|
|
|
|
George_George wrote: "except that the caller doesn't get blocked if the worker's already busy with a task", any ideas?
Yes this is true. Caller won't be blocked. The example uses a queue system. When you enqueue new task, it will be added to the queue and immediately control will be given back. The program then processes each task depending on the availability of worker threads.
|
|
|
|
|
Thanks N a v a n e e t h,
1.
N a v a n e e t h wrote: Yes this is true. Caller won't be blocked. The example uses a queue system. When you enqueue new task, it will be added to the queue and immediately control will be given back. The program then processes each task depending on the availability of worker threads.
I agree. But the Enqueue operation will be blocked since it is using a lock object to do synchronization, right? Means if worker thread is at the same time Dequeue, the person who Enqueues must wait.
2.
I have an alternative implementation, which will use the following logics,
2.1 Sleep 1 second;
2.2 Check is a bool variable called stop is set by some other threads?
2.3 If stop is set, then stop current thread;
2.4 If stop is not set, then do some regular work, then go back to 2.1.
Does using event (as showed in the document you referred) has better performance compared with my alternative method?
regards,
George
|
|
|
|
|
George_George wrote: But the Enqueue operation will be blocked since it is using a lock object to do synchronization, right? Means if worker thread is at the same time Dequeue, the person who Enqueues must wait.
No. It won't block. You know, acquiring a lock is pretty fast. If you look at that code carefully, you will find lock is used only to dequeue items, and it will be released immediately once dequeued. Program won't hold the lock until it finishes executing the job. So it executes in a nonblocking fashion.
George_George wrote: Does using event (as showed in the document you referred) has better performance compared with my alternative method?
The example which I showed utilizes CPU well. It won't create much threads for processing each task. It will use the existing threads to spin between the tasks. A free thread will be allocated to process the next task.
Will the steps you provided satisfy your requirement ? As I understood from the previous messages, you are trying to execute a task before the previous task completes. I mean you need to execute it in each 1 second without blocking. If it is the case, looks like the steps you provided won't satisfy the requirement.
According to your code, when a task is processed, it is not checking the stop flag. So it won't exit until the currently processing task ends. Right ? Also it will block the thread until it finishes the operation, so you can't guarantee that it will be executed in each 1 second. Correct me if I got you wrong.
|
|
|
|
|
Thanks for your great reply, N a v a n e e t h!
Three more comments after some thinking. 
1.
N a v a n e e t h wrote: only to dequeue items
No. When Enqueue, the lock is still used.
Here is the code. Any comments?
public void EnqueueTask (string task) {
lock (locker) tasks.Enqueue (task);
wh.Set();
}
2.
N a v a n e e t h wrote: It won't create much threads for processing each task. It will use the existing threads to spin between the tasks.
Which solution do you compare to when you mention "create much threads"? In my case, I only create one thread in the very first post.
If I use timer, then each time, the timer will create a new worker thread or reuse previous one?
3.
N a v a n e e t h wrote: Will the steps you provided satisfy your requirement ? As I understood from the previous messages, you are trying to execute a task before the previous task completes. I mean you need to execute it in each 1 second without blocking. If it is the case, looks like the steps you provided won't satisfy the requirement.
Sorry my English is not very good.
My requirement is to complete the current task before execute next task, and between each task execution iteration, sleep 1 second so that system could have more chances to do other things. Could you help to review my previous solution again to see whether it could achive requirement please?
regards,
George
|
|
|
|
|
George_George wrote: No. When Enqueue, the lock is still used.
Yes. Enqueue is fast and it won't block thread for anytime.
George_George wrote: If I use timer, then each time, the timer will create a new worker thread or reuse previous one?
Timer uses thread pool thread. Obviously it will be reused.
George_George wrote: My requirement is to complete the current task before execute next task, and between each task execution iteration, sleep 1 second so that system could have more chances to do other things
Either you can do parallel execution or sequential execution. If you need to execute the next only after the completion of first task, then you don't need such a producer/consumer solution.
|
|
|
|
|
Thanks N a v a n e e t h,
1.
Compared my original solution with using Timer, I think the advantage is I am using a single thread to execute (while Timer will use thread pool, not sure whether it is always the same thread), but disadvantege is I need to call sleep in order to execute next task.
So, I am confused, whether the performance of using Timer or using Sleep is better (I mean less performance overhead to the whole application)?
2.
N a v a n e e t h wrote: Either you can do parallel execution or sequential execution. If you need to execute the next only after the completion of first task, then you don't need such a producer/consumer solution.
Sorry, I have not made myself understood. What I am doing is the same as the producer/consumer scenario. The thread I described in my original very first post is the consumer thread, another thread is controller for push task for consumer and set stop status.
regards,
George
|
|
|
|
|
George_George wrote: Compared my original solution with using Timer, I think the advantage is I am using a single thread to execute (while Timer will use thread pool, not sure whether it is always the same thread), but disadvantege is I need to call sleep in order to execute next task.
Both will be same in this case. Timer uses a thread pool thread which is ready to go. So you can avoid the overhead of creating your own threads. You know, creating a thread is bit performance costly.
|
|
|
|
|
Thanks N a v a n e e t h,
I agree. Then what do you think are the pros and cons of using Timer compared with using Sleep, functional and performance?
regards,
George
|
|
|
|
|
I don't know exactly. Since timer uses a thread pool thread, I guess sleeping for a long time is bad as thread pool is shared.
|
|
|
|
|
Thanks N a v a n e e t h,
"sleeping for a long time is bad as thread pool is shared" -- I am confused. Do you mean if we use thread pool thread, and we "hold" the thread too long (e.g. using Sleep), then it will reduce the chance for other parties to use/share the same thread from the thread pool?
regards,
George
|
|
|
|
|
|
Compared of using Timer, maybe this solution is of better performance (means less performance impact to the whole system)? Any comments?
while (false == StopEvent.WaitOne(1000))
{
}
regards,
George
|
|
|
|
|
That's how I write Services. I use a Timer. If the process needs the ability to stop part way through then I also use a semaphore. In some cases, the Service runs a method in another class (with another semaphore) and that class has an event that the Service can raise to stop that method.
|
|
|
|
|
Thanks PIEBALDconsult,
"If the process needs the ability to stop part way through then I also use a semaphore. In some cases, the Service runs a method in another class (with another semaphore) and that class has an event that the Service can raise to stop that method." -- I am confused whether you are using event or semaphore or both? Could you show me your pseudo code please? Code clarifies much more.
regards,
George
|
|
|
|
|
Both; the second class' event handler sets its semaphore.
George_George wrote: Could you show me your pseudo code
I could, and I'll try to, but it's late now.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
