OpenEuphoria

Re: Multitasking question

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 16, 2006
• 475 views

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