The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Design related question

I want my application to do three tasks simultaneously. Each of the three tasks must be performed at a periodic interval of time. Each of the three tasks is somewhat complicated and is thus composed of a number of sub-tasks that are to be performed in a linear sequence.

The three tasks are independent of each other. They do not share any data, nor is the execution of one going to affect the other.


To ampify, assume I have three main tasks as:

Task A [performed simultaneously with Task B and Task C]
    - Sub-task A.1 (sub-task within Task A)
    - Sub-task A.2 (performed in linear sequence after A.1)
    - Sub-task A.3 (performed after A.2)


Task B
    - Sub-task B.1 (sub-task within Task B)
    - Sub-task B.2 (performed in linear sequence after B.1)
    - Sub-task B.3 (performed after B.2)


Task C
    - Sub-task C.1 (sub-task within Task C)
    - Sub-task C.2 (performed in linear sequence after C.1)
    - Sub-task C.3 (performed after C.2)



The question is: how should I design my application. I am thinking of the following options:

1. One glob executable that runs as a service and manages Task A, Task B and Task C as three separate threads. Each thread fires off a timer so that the thread is always active and it executes periodically.

This will, however, involve a buttload of thread management. Also, if one thread misbehaves, the whole application will come to a halt. It would be wrong to couple them in one process given that the tasks are independent of each other.


2. Make each task into a separate EXE. In each EXE, take a timer that executes the sub-tasks in linear sequence.

Create a Windows Service that watches over these independent process. If one of them crashes or misbehaves, the Windows Service writes to the Event Log, cleans up memory and re-starts the process afresh.


If you were in my position, what would your take on the design be? What would you recommend?
Water Cooler v2 Send private email
Tuesday, July 11, 2006
 
 
Three exes.

One day, you might want to put that on three separate CPUs.
Architecture Astronaut
Tuesday, July 11, 2006
 
 
==> One day, you might want to put that on three separate CPUs.

I don't do multi-threading in the apps I write, so this is a question of ignorance here: Are you saying that all threads for a single .exe must run on the same processor?
What's that about?!?? I develop extensively on SQL Server, and at one installation it's running on a total of 8 CPUs. I don't see 8 separate SQL .exe files. Something doesn't sound right with that.
Sgt.Sausage
Tuesday, July 11, 2006
 
 
Different threads from the same process can run on different CPU's, but they use the same memory space, so that's the theoretical bottleneck.  If you're doing different .exes though, it'd be easier to move to a distributed system where each .exe runs on a different box.

Back to the original question though: How resource intensive are the operations? How soft or hard are your realtime requirements? What language/environment are you using?

For example, in .NET a misbehaving thread will just kill itself, so it won't have any impact on the other threads and is a non-issue.  On the other hand, in C or C++ a bad pointer could take down the whole app.

Since you're not using shared memory, you really shouldn't have too much to deal with in terms of thread management in the code.
Grant
Tuesday, July 11, 2006
 
 
I would vote for threads.

That said, I'd have to ask why the application needs to do three separate tasks concurrently. One of the significant issues people need to deal with when doing parallel programming is reconciling the "end results".

With threads and shared memory, it's easy for each thread to write to a unique address, or otherwise spin lock the destination. With separate executables, you get into the messier realm of message passing, master-slave or similar relationships.

Having said that, it's also possible that tasks A, B, and C produce independent results that have no bearing on each other. But as I implied before, if that's the case, then why go to the extra overhead of doing them simultaneously? Just do A, then B, then C, or alternatively, fork() them as needed.
TheDavid
Tuesday, July 11, 2006
 
 
2. Definitely 2.
A. Nonymous
Wednesday, July 12, 2006
 
 
In fact, why not let the service launch each .exe when it needs to run?
A. Nonymous
Wednesday, July 12, 2006
 
 
>>In fact, why not let the service launch each .exe when it needs to run?

This is what our app does.  The entire package consists of 3 user applications (security, admin tasks, and operational tasks) and 8 other EXEs that run as on-demand services.  One is a manager that monitors job queues, launches the EXEs and can kill & restart them if needed.  The individual services can run on any box as long as they can reach the database.  We also allow multiple instances of some of them to speed overall throughput. 

For our purposes, managing EXEs is simpler to code, test and debug than managing threads.
a former big-fiver Send private email
Thursday, July 13, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz