Re: [Algorithms] General purpose task parallel threading approach

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

>If the operation in turn needs another
>task to complete, which may be later in the work queue, or require
>locks/resources currently held by the fiber doing the cancellation
That's no problem in my implementation. Both tasks will be suspended until
non-cancellable wait operation finishes, and worker thread will be working
on something else. Also async::Task::Cancel only marks a task for
cancelling, you need to explicitly wait on a task to finish to reach the
point where a cancelled task doesn't exist.

If in turn wait operation never expires, then it is a problem in the task
logic, and canceling is not supposed to fix that.

I already have a dosen of application written with asynclib, and strict user
control for what to cancel and what not  turned out to be the best thing.
You can still apply your own use, and make each operation cancellable and
throw exception - it is up to you.

Alexander.

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

> asy...@gm... wrote:
> > Where do you get a deadlock from ?
>
> If a specific operation is not cancellable, and waits for completion no
> matter what, then that means that cancelling the fiber will have to wait
> for that operation to complete. If the operation in turn needs another
> task to complete, which may be later in the work queue, or require
> locks/resources currently held by the fiber doing the cancellation, then
> you have a deadlock.
>
> In general, non-cancellable operations are bad (similar to
> non-signal-breakable syscalls in UNIX). The right thing to do is to make
> any operation cancellable, and we've found that the best way to make
> sure nobody does the wrong thing is to simply throw an exception out of
> the yield call when an operation is cancelled. Proper use of smart
> pointers and RAII will then take care of the unwind semantics.
>
> That being said, blocking is still rare in game loops; we use all of
> this only for the transactional application server back-end.
>
> Sincerely,
>
> jw
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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