1. Multitasking question
I am worried by the following scenario, which is bound to happen more and
more as using of tasks will spread.
lib1.e has a routine r1 which accesses a local variable v1. For instance, r1
may be recursive and v1 holds intermediate results. It does not use threads.
It calls a routine r2 in a third party lib2.e
Currently, lib2.e doesn't use threads, and everything works as expected.
lib2.e gets upgraded so that r2() now has a task_yield() statement in it.
The task switch that will occur then may well cause a thread to execute r1()
again using a new value for v1. Code in lib1.e then randomly crashes as,
when it resumes, r1() does not find consistent values in v1. Or worse yet,
it may not crash but produce unexpected results.
I think there is a real need for some mechanism to preserve local
(filewide) variables in a multitasking environement, even cooperative, as
the example above shows.
Several possibilities can be explored:
1/ introduce a new "thread" prefix for variables. It will instruct the
interpreter to define multiple instances of the variable, one for each
thread that ever accesses it. An error should be raised if "thread" is used
with a routine, global variable or private variable.
2/ Diminish the necessity of local variables by introducing symbols shared
between routines. You might then have:
integer n
function f1()
-- some code here
end function
function f2()
-- some more code here
end function
share n r1,r2
The last line would instruct the interpreter to treat n as a private
variable common to r1 and r2, and no longer as a local symbol.
"share n r1" then would be equivalent to "share n between all active
instances of r1", in other words, would define a static variable.
If allowed for global symbols, this would allow routines to exchange
information without polluting the unnamed namespace, which would greatly
help Eu being more modular.
CChris
2. Re: Multitasking question
Cuvier Christian wrote:
>
> I am worried by the following scenario, which is bound to happen more and
> more as using of tasks will spread.
>
> lib1.e has a routine r1 which accesses a local variable v1. For instance, r1
> may be recursive and v1 holds intermediate results. It does not use threads.
> It calls a routine r2 in a third party lib2.e
>
> Currently, lib2.e doesn't use threads, and everything works as expected.
>
> lib2.e gets upgraded so that r2() now has a task_yield() statement in it.
> The task switch that will occur then may well cause a thread to execute r1()
> again using a new value for v1. Code in lib1.e then randomly crashes as,
> when it resumes, r1() does not find consistent values in v1. Or worse yet,
> it may not crash but produce unexpected results.
>
> I think there is a real need for some mechanism to preserve local
> (filewide) variables in a multitasking environement, even cooperative, as
> the example above shows.
>
> Several possibilities can be explored:
>
> 1/ introduce a new "thread" prefix for variables. It will instruct the
> interpreter to define multiple instances of the variable, one for each
> thread that ever accesses it. An error should be raised if "thread" is used
> with a routine, global variable or private variable.
>
> 2/ Diminish the necessity of local variables by introducing symbols shared
> between routines. You might then have:
>
> }}}
<eucode>
> integer n
>
> function f1()
> -- some code here
> end function
>
> function f2()
> -- some more code here
> end function
>
> share n r1,r2
> </eucode>
{{{
>
> The last line would instruct the interpreter to treat n as a private
> variable common to r1 and r2, and no longer as a local symbol.
>
> "share n r1" then would be equivalent to "share n between all active
> instances of r1", in other words, would define a static variable.
>
> If allowed for global symbols, this would allow routines to exchange
> information without polluting the unnamed namespace, which would greatly
> help Eu being more modular.
>
> CChris
>
>
I don't think that it works that way. If r1() is not a multitasking routine
(does not have a task_id() associated with it) then it will not be multitasked.
The call to task_yield() in r2() will just allow the scheduler to run other
routines that have been *specifically designated* as tasks.
Now if you have two tasking routines in one include that both adjust the same
file-level variable, you could cause problems if you are not careful. But since
it is cooperative tasking and not pre-emptive, variable locking mechanisms should
be relatively simple.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
j.
3. Re: Multitasking question
Cuvier Christian wrote:
> I am worried by the following scenario, which is bound to happen more and
> more as using of tasks will spread.
>
> lib1.e has a routine r1 which accesses a local variable v1. For instance, r1
> may be recursive and v1 holds intermediate results. It does not use threads.
> It calls a routine r2 in a third party lib2.e
>
> Currently, lib2.e doesn't use threads, and everything works as expected.
>
> lib2.e gets upgraded so that r2() now has a task_yield() statement in it.
> The task switch that will occur then may well cause a thread to execute r1()
> again using a new value for v1. Code in lib1.e then randomly crashes as,
> when it resumes, r1() does not find consistent values in v1. Or worse yet,
> it may not crash but produce unexpected results.
>
> I think there is a real need for some mechanism to preserve local
> (filewide) variables in a multitasking environement, even cooperative, as
> the example above shows.
>
> Several possibilities can be explored:
>
> 1/ introduce a new "thread" prefix for variables. It will instruct the
> interpreter to define multiple instances of the variable, one for each
> thread that ever accesses it. An error should be raised if "thread" is used
> with a routine, global variable or private variable.
>
> 2/ Diminish the necessity of local variables by introducing symbols shared
> between routines. You might then have:
>
> }}}
<eucode>
> integer n
>
> function f1()
> -- some code here
> end function
>
> function f2()
> -- some more code here
> end function
>
> share n r1,r2
> </eucode>
{{{
>
> The last line would instruct the interpreter to treat n as a private
> variable common to r1 and r2, and no longer as a local symbol.
>
> "share n r1" then would be equivalent to "share n between all active
> instances of r1", in other words, would define a static variable.
>
> If allowed for global symbols, this would allow routines to exchange
> information without polluting the unnamed namespace, which would greatly
> help Eu being more modular.
These are interesting ideas, but I don't think
any of us has enough hands-on experience with
multiple tasks to guess right now what future
enhancements will be needed.
I've done some small multitasking demos, plus
Language War, which makes very sophisticated use
of the feature. I didn't see the problems that you describe
as being severe. For example, if simultaneous updates are a concern,
a library routine could be run by a single task, set up to process a queue.
That way, many tasks could feed information into the queue, and the single
task could process the information, without risk of corrupting
data structures. Many library routines have no "state", so any
number of tasks could be executing them at the same time without a problem.
The person who designs the tasks just has to be aware of the
possible concurrency problems. With cooperative tasking, it's
a lot easier to do this, than with pre-emptive tasking. You simply
hang onto the CPU, and do whatever you have to do,
before letting another task get control. Granted, when there is
more than one programmer involved, the chance of a mistake
will increase.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
