[dba-VB] System.Timers.Timer()

Salakhetdinov Shamil mcp2004 at mail.ru
Tue May 15 15:12:50 CDT 2012

John --

So, you do not have any periodically (by given schedule) running main tasks (consisting of (three subtasks)) - what you have  (a bit simplified in this description) are three main tasks, which can be activated/deactivated by using three check-boxes(/ or just one checkbox?), and every main task consists of three subtasks...

...I'm not sure what for timers are needed in your case at all? Timers (IMO)  (as used in this subject thread rel life case) are a real bottleneck for (unlimited scaling) and a source of issues for multi-threading: for race conditions and maybe deadlocking etc.

I'd use (out of the head with some googling - it have to be verified): 

- .NET Task Parallel Library (TPL) (http://msdn.microsoft.com/en-us/library/dd235608, http://www.codeproject.com/Articles/189374/The-Basics-of-Task-Parallelism-via-C) to run/cancel (by flag/checkbox or timeout) main as well as subtasks (read more carefully on CancellationToken);
- ConcurrentQueue (http://msdn.microsoft.com/en-us/library/System.Collections.Concurrent) to post main task activation requests when "activation checkboxes" are clicked;

.NET Windows Workflow Foundation (WF) should be also possible to use for your case but I have no experience with it yet to advise but I suppose that if you'd use/get experience with TPL then learning/using WF would be easier and "armored with WF" you'll get unlimited smooth scaling opportunity in your  hands... 

If you will decide to go with .NET TPL classes as well as with  System.Collections.Concurrent classes then be prepared for a steep learning curve - don't try to rewrite all your subject solution classes at once using TPL/Concurrent collections - go step by step - at least it was my case - I have TPL/concurrent collections used in several customer solutions running smoothly 24x7x365 with some long running tasks(threads) running for hours as well small tasks, all with UI interaction/running status display, immediate cancelling features etc. ...

Thank you.

-- Shamil

Tue, 15 May 2012 14:25:17 -0400 от jwcolby <jwcolby at colbyconsulting.com>:
>  > Is it correct understanding that you have a set of tasks to run periodically, fired by specified 
> timer intervals, and when one task is running all the others are blocked?
> No.  I actually have three main tasks (driven by timers) *possibly* running (which I call "stages"), 
> but I have 6 timers *possibly* running plus the interface thread.
> None of the tasks block any of the other tasks.
> I use the timers in my clsRunState.  The run state class may monitor the click event of a dedicated 
> check box which is how I start and stop each of the main tasks.  So by checking a check box, I start 
> one of the three stages.  Each stage has its own check box so I can have 0 to 3 stages running 
> simultaneously.
> Stage1 exports data to disk files.
> Stage2 pushes the files exported by stage1 to 0 to 3 virtual machines for third party processing, 
> and pulls it back out of the VMs when finished.
> Stage3 pulls the processed files back into SQL Server.
> The reason that there are 6 timers is that clsAZManager "manages" or schedules the stages.  Its job 
> is to select which supervisor is running at a given stage.  So there are three timers in clsManager 
> tied to check boxes on the form which just continuously look for work for the associated stage.
> However once clsManager selects a clsupervisor instance for stage1 (for instance) the supervisor has 
> its own timer which it uses to perform the work for the indicated stage.  So *potentially* three 
> stage timers in clsManager all firing, and *potentially* three stage timers in clsSupervisor 
> instances doing the actual work.
> None of these timers block any of the other timers, however the user interface (checkboxes) has to 
> be able to start and stop any given stage.
> Stages 1 and 3 in particular can be long running processes, taking as long as 30 seconds to a minute 
> or so to process from start to finish.  So once a supervisor kicks off exporting a file to disk 
> (stage1) it can't be shut down until that process finishes.  Once a supervisor kicks off importing a 
> file back in to sql server (stage 3) it can't shut down until that process finished.  So I may 
> "uncheck" the stage3 checkbox but it might be several minutes before the process actually stops for 
> that supervisor.
> I was (apparently) very occasionally getting a race condition as I would try to stop a stage, thus 
> the implementation of clsTimer which I use in place of a direct timer instance (which I was using). 
>   clsTimer implements the handshaking to prevent the race condition, and does so in a clean single 
> location (OOP).
> John W. Colby
> Colby Consulting
> Reality is what refuses to go away
> when you do not believe in it
> On 5/15/2012 1:48 PM, Salakhetdinov Shamil wrote:
> > Hi John --
> >
> > Is it correct understanding that you have a set of tasks to run periodically, fired by specified timer intervals, and when one task is running all the others are blocked?
> >
> > Thank you.
> >
> > -- Shamil
> >
> >
> > Tue, 15 May 2012 10:28:48 -0400 от jwcolby<jwcolby at colbyconsulting.com>:
> >> Is anyone using timers to periodically run processes?
> >>
> >> I am (was hopefully?) having problems with apparent deadlocks and I found this on the MS site:

More information about the dba-VB mailing list