1. Multitasking question
- Posted by Cuvier Christian <christian.cuvier at insee.fr> Feb 15, 2006
- 439 views
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
- Posted by Jason Gade <jaygade at yahoo.com> Feb 15, 2006
- 447 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.
3. Re: Multitasking question
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 16, 2006
- 476 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