Re: tasks as part of record

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 06 Oct 2014 10:18:07 +0300, Niklas Holsti wrote:

> On 14-10-06 06:47 , Stribor40 wrote:
>> I though it would be easier if task is componenet of record.
> 
> *What* would be easier?
> 
> Tasks are intended for a specific purpose, which is useful in *some*
> applications: to execute separate threads of control concurrently, and
> possibly in parallel if the computer has several processors.
> 
> As I said before, it is unusual for an application to require a separate
> task for each data object (= student record), and such designs are
> usually complex and inefficient.

Well, actually it is not so unusual. The software pattern is called "active
object".

You are right it is not easy. However, concerning easier or not, what is
the alternative? Two separate yet coupled objects (task and record)? That
is not necessarily easier. Actually there are three variants all already
mentioned in the thread:

1. Separate record and task one referencing another;
2. Task in a limited record with an access discriminant to;
3. Data hidden in the task, exposed via task's entry.

#1 is a mess;

#2 is active object and has issues with initialization/finalization and
most likely will break under inheritance;

#3 is heavy-weight and coarse because all interfacing go though entries,
entries may have no results, tasks are non-tagged.

But the question is *what*, as you said.

>> i would like to operate on components of student record. 
>> For example for each student there will be one tasks.
> 
> Why? Why do you need concurrent / parallel execution of student operations?

A simulation?
 
> I suspect strongly that using tasks at all in your application is
> unnecessary, and only complicates the design, which is why I would like
> to understand why your application needs concurrency.

Exactly. Before discussing a solution there must be the problem stated.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de