OpenEuphoria

Re: Multitasking question

• Posted by Jason Gade <jaygade at yahoo.com> Feb 15, 2006
• 448 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.
> 
> 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.