Re: [Tbb-develop] Task I/O Blocking Plans

[Robison, A. <arc...@in...>]

We haven't figured it all out yet.  Yes, each blocked task will cause a
new operating system to spawn.  Or we might have a way to mark a task as
blocking, so that the scheduler can put the task on its own thread to
start with.  That's a crude solution, but has some merit.  Unfortunately
any task that waits on that task becomes blocking itself.

=20

The root problem is that the space guarantees have to be weakened.  With
a Cilk-style scheduler as in TBB, there's a guarantee that if a program
runs in space S on a single processor, it does not exceed space P*S when
run by P threads.  If we allow blocking, then K blocked tasks obviously
require at least space K.  We also want to have no more than P threads
running at any given time, in order to avoid oversubscription.  I've
been thinking about ways we might approximate this ideal when there are
threads blocking and unblocking.

=20

- Arch =20

=20

________________________________

From: tbb...@li...
[mailto:tbb...@li...] On Behalf Of Adrien
Guillon
Sent: Friday, October 12, 2007 7:27 AM
To: Tbb...@li...
Subject: [Tbb-develop] Task I/O Blocking Plans

=20

Hello All,

I read about the plans for tasks to be able to block on I/O in future on
the main site.  Is there a location where I could find information on
the planned development of this feature?  I'm interested in a high-level
conceptual view of how tasks are going to be able to block.
Specifically, how is this going to affect task to thread association,
and the scheduling algorithm?  For instance, will each blocked task
cause a new operating system thread to be spawned?=20

Thanks!

AJ