Re: Multitasking Preview Release
Michael Nelson wrote:
> I really like the new task API. Robert can do things with it that just
> simply be done in a library by building it into the interpreter. But the
> ideal of zero cost for programs that don't use it will not be realized
> in all cases.
>
> A case in point is my own Method Euphoria. I maitain a great deal of
> state information, inlcuding a call stack which tracks the "this"
> pointer, the currently running method, and various other things needed
> to enforce access rights--ME can only enforce protected or private
> access to a method because it tracks what method is callng it.
>
> If I make a task-safe version, I will need to maintain this data on a
> per task basis. So the state variables that are now integers become
> sequences, and those that are sequences become nested one level deeper.
> Every ME operation which acesses this state information will have an
> extra level of subscipting for each access (may be reduced somewhat but
> not eliminated by the creative use of temporaries).
That's one way to do it.
I haven't looked into the details of ME,
but couldn't you do a full context switch of all of your ME data
after each task_yield(), and also at the start of a new task,
such that you copy (this may be just a pointer copy internally)
all the ME data for the new current task
into the simple variables that you use today? e.g.
me_data1 = all_tasks_me_data1[task_self()]
me_data2 = all_tasks_me_data2[task_self()]
...
You could create an ME context-switch routine for this,
and maybe create a wrapped version of task_yield()
to add this extra operation.
It would be extra overhead at each context switch,
but if the user did not use multitasking, he wouldn't need it,
and he would have little or no overhead.
You could also retain the structure of all the
ME internal variables you are using now.
> In addition, each
> operation will require a call to task_self.
task_self() is a built-in function.
Its cost is no higher than adding two integers.
> This will cause ME programs
> to run slower, even if they never use tasking.
>
> This issue will affect any library which maintains state information per
> program that would need to shift to maintaining state information per task.
I think most libraries could use a similar context-switching approach,
but, yes, some library writers will now have to consider what to do
if their users want to call the library from multiple tasks.
In some cases the multiple tasks will act in concert, as one logical
"user" of the library, with one set of global state information.
In other cases, the library writer may want to maintain separate
state information for each task. At least, with *cooperative* multitasking,
it's easy to avoid the scary situation where two or more tasks might
be executing inside the same library at the same time.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
