Help me design my scheduler

[Guest]

Anyone know of a reliable design for a Windows C++ Task Scheduler
Class.
The scheduler will expose a member function that will add schedules,
its parameters will be an interval to run the tasks and a function
pointer. This function pointer will be a void* function in other
objects that will use the scheduler.


So when another object calls the addSchedule function the scheduler
will run these tasks at each interval provided. There may be a number
of tasks running at the same time.

Should I design this as single or multi threaded, it seems I need to
make it multi threaded as I may have to use a waitable timer? But would
prefer the debugging ease of a single threaded design.

Should I make the scheduler a singleon?

There is an example quite similar at:
http://www.codeguru.com/Cpp/W-P/system/misc/article.php/c5783/

But this example does not work in a Windows Service and when I use a
waitable timer I have to make it multithreaded.

So any ideas\pointers\links for me on a good base design for this
class.

Enda

 

[mlimber]

Anyone know of a reliable design for a Windows C++ Task Scheduler
Class.
The scheduler will expose a member function that will add schedules,
its parameters will be an interval to run the tasks and a function
pointer. This function pointer will be a void* function in other
objects that will use the scheduler.


So when another object calls the addSchedule function the scheduler
will run these tasks at each interval provided. There may be a number
of tasks running at the same time.

Should I design this as single or multi threaded, it seems I need to
make it multi threaded as I may have to use a waitable timer? But would
prefer the debugging ease of a single threaded design.

Should I make the scheduler a singleon?

There is an example quite similar at:
http://www.codeguru.com/Cpp/W-P/system/misc/article.php/c5783/

But this example does not work in a Windows Service and when I use a
waitable timer I have to make it multithreaded.

So any ideas\pointers\links for me on a good base design for this
class.

Enda

This newsgroup is for standard C++ language issues, and since the
standard knows nothing of threading, your questions fall outside the
scope of the group. You'll likely get better help in the group you
cross-posted to: comp.os.ms-windows.programmer.win32.

Cheers! --M

 

[Guest]

Well... there was a reference in my question to a Singleton class and a
general design for my class. Also in designing this class it seems
that it would be quite important to keep threading in mind.

Also thanks for the alternative group.

Anyway I have came up with a soloution and it involves exposing an
addSchedule function when called the first time a thread is created
and the waitable timer is created and setup. Subsequent calls to this
function will not create the thread again or create the timer just
update the timer.

The task is appended to a linked list of tasks that is another object.

When the timer expires the function is run.

Enda

 

[mlimber]

Well... there was a reference in my question to a Singleton class and a
general design for my class. Also in designing this class it seems
that it would be quite important to keep threading in mind.

[snip]

As to the singleton, that's technically not a C++ language question
either. (Implementation is another story -- see _Modern C++ Design_ for
more than you ever wanted to know about implementing singletons.) In
any case, making the scheduler a singleton obviously depends on whether
you can have more than one instance of it. If there can by definition
only be one in your application, then a singleton seems like a good
idea. If you will have multiple schedulers to handle different sets of
tasks or whatever, then obviously you shouldn't make it a singleton. We
don't really know enough about your application to provide direct
advice on that front.

If by "tasks" you mean other processes on the windows machine, then
making it a singleton probably doesn't matter because you're providing
access to the scheduler through COM or some other such interface.
(You'll need to decide if there can be more than one instance of the
scheduler process running, but that's not a singleton in the C++ sense
and is well outside the scope of this NG.)

Cheers! --M

 

[Kai-Uwe Bux]

Anyone know of a reliable design for a Windows C++ Task Scheduler
Class.

It is very unfortunate, but the C++ language specification does not mention
threads at all. Not only puts that multi-threading somewhat out of the
scope of this news group, but it also makes it close to impossible to argue
the correctness of a multi-threaded C++ program. If you want to know about
the particular API and guarantees of certain threading libraries, your best
bet would be a newsgroup for your platform.

Some basic threading support is also offered in boost, if I recall
correctly.

The scheduler will expose a member function that will add schedules,
its parameters will be an interval to run the tasks and a function
pointer. This function pointer will be a void* function in other
objects that will use the scheduler.


So when another object calls the addSchedule function the scheduler
will run these tasks at each interval provided. There may be a number
of tasks running at the same time.

Should I design this as single or multi threaded, it seems I need to
make it multi threaded as I may have to use a waitable timer? But would
prefer the debugging ease of a single threaded design.

Should I make the scheduler a singleon?

I do not see a reason for that. If I understand you correctly, the program
could register a function pointer with a scheduler and create a thread that
way. I consider it perfectly feasible to create another scheduler, say
within a given thread, and recursively register sub-threads with the local
scheduler object. This kind of recursive scheduling strategy is actually
used every once in a while. So why preclude it by design of the scheduler
class?

There is nothing inherently unique about a scheduler object. If your
application, by conincidence, does not need more than one scheduler, just
do not create another scheduler object. [This is very similar to clocks:
most programs happen to use at most one, but there is nothing inherently
unique about clocks, so I do not see any reasons to make a Clock class a
singleton.]


Best

Kai-Uwe Bux