Re: [Algorithms] General purpose task parallel threading approach

[<asy...@gm...>]

Ok, regarding point 2, isn't the following pseudo-code does what you want  ?

void  TaskWhichWaitsForDepsToComplete()
{
    async::Task *TaskA, *TaskB, *TaskC;

    ... do some work here

    async::Execute(TaskAProc, &TaskA, ...);

    ... do some more work here

    async::Execute(TaskBProc, &TaskB, ...);

    ... do some more work here

    async::Execute(TaskCProc, &TaskC, ...);

    ... do even more work here

    async::WaitAll(*TaskA, *TaskB, *TaskC); // this call makes a task wait
for tasks A,B,C. Optionally it can either help out worker threads while
waiting, or it can simply block

    TaskA->Release(); TaskB->Release(); TaskC->Release();


    ... finally do some work at the end of task

   return;  // done!
};

void main()
{
  async::Task* TheTask;

  async::Execute(&TaskWhichWaitsForDepsToComplete, &TheTask, ...);

  async::Wait(*TheTask);

  TheTask->Release();
}

You can additionally put any other primitive into async::Wait, and you can
put as many of those as you want.

As an example, you can even achieve point 2 in a different way:

void DependeeTask(void* pSemaphore)
{
   ... do work
  ((async::Semaphore*) pSemaphore)->Release();
}

void MainTask()
{
   int nDependiesToSpawn = xxx;

   async::Semaphose DependendsSemaphore;  // create a semaphore on the
stack, which is actually an 8 bytes zero initialized

   for (int i = 0; i < nDependiesToSpawn; ++i)
     asyn::Execute(&DependeeTask, &DependendsSemaphore, ...);

   DependendsSemaphore.Achquire(nDependiesToSpawn);  //waits until all task
release the semaphore, which happens at the end of task
}




Now regarding point 1:

void ThisTaskWillBeExecutedInsideWorkerThread()
{
  printf("hello");
}

void TaskWhichExecutesCodeInsideTheWorkerThreadStack(void* pUserData)
{
    // assuming that pData holds a pointer to what actually needs to be
executed

    async::ExecuteAsThread((void* (*)(void*)) pData); // executes a function
in the stack of the worker thread - this is a veeery lightweight function
(check with the debugger if you don't beleive me)
}


void main()
{
   async::Task* TheTask;
   async::Execute(&TaskWhichExecutesCodeInsideTheWorkerThreadStack,
                          &ThisTaskWillBeExecutedInsideWorkerThread, // user
data pointer
                          &TheTask
                          ...,
                          async::MINIMAL_TASK_SIZE); // 32 bytes for task
structure

   async::Wait(*TheTask);

   TheTask->Release();
}


This code does exactly what you require under point1. I can create an option
which will not require you to create a wrapper function (which is
TaskWhichExecutesCodeInsideTheWorkerThreadStack in this example).


Would that solution suit you for both points 1 and 2 ?


Alexander.




2009/4/14 Jon Watte <jw...@gm...>

> asy...@gm... wrote:
> > I still didn't get a clear picture of what I need to change to make
> > asynclib an attractive threading library for games.
>
> As seen from my point of view, the two top-level changes would be:
>
> 1) Don't allocate a stack per task. Instead, allocate a stack per worker
> thread. (The bonus is that these stacks can be large enough to be
> useful, without too much overhead)
>
> 2) Let each task have a dependency tree, where a task will automatically
> become runnable when all its dependencies are complete (and a typical
> dependency will be the completion of some other task).
>
> Now, if you really want to support arbitrary blocking within the
> execution of a micro-task (which I feel is a mistake), then you can make
> it so that you allocate a new stack for the next task only when some
> stack is "used" because there is a blocking task.
>
> Sincerely,
>
> jw
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Regards,
Alexander Karnakov