Menu
▾
▴
tbb-develop — for developers working on TBB
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(7) |
Oct
(12) |
Nov
(9) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(4) |
Feb
(12) |
Mar
(23) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Reed, R. W <rob...@in...> - 2007-10-31 23:08:36
|
Well, a file descriptor is a process-level entity, not a thread-level entity so there should not be a problem with sharing descriptors between threads, and it probably makes more sense to use a blocking I/O wait (e.g., select on Linux or WaitForMultipleObjects on Windows) rather than polling the descriptors. But assigning all I/O to a single thread essentially serializes the I/O, which is probably not a good thing for scalability. Having a way to ensure all processors can be kept busy processing available work while one or more threads are blocked waiting for I/O would allow applications to maximize concurrency. You can adjust the count of threads created in the pool by the task_scheduler_init constructor and thereby have threads to take up the slack if one of the threads is blocked in an I/O wait, but this is a hack that may be more trouble than it's worth. The trouble is that when you don't have such I/O in progress, you have too many threads in the pool, which can lead to all the woes of oversubscription. Some better solution is needed. But I wouldn't hold my breath for "blocking algorithmic tasks." Such artificial waits are anathema to the design goals of TBB, which wants to complete tasks that have already started and may thus have data already in cache. Nor would I expect low-level thread details to be exposed except where absolutely necessary. The TBB philosophy is to divorce the developer from knowledge and control of particular threads as much as possible because that's the domain of the task scheduler. Some warts may eventually appear to support latency hiding operations such as asynchronous I/O, but only in a fashion consistent with the rest of the TBB threading model and where there are clear performance advantages. |
|
From: Arun S. <ads...@us...> - 2007-10-31 05:03:16
|
On Oct 30, 2007 9:49 PM, Reed, Robert W <rob...@in...> wrote: > listed below. I tested the link and it does work. That new link should > be stable. Thanks for confirming. Please let me know if you have any questions about the patch. -Arun |
|
From: Kevin F. <ke...@or...> - 2007-10-31 03:54:56
|
Arun, I'm not sure what happened with the link. I know that the TBB Contributions process is in a state of ongoing development, so possibly that has something to do with the link being changed. Another thing that is happening is that the Threading Building Blocks site is being migrated to its own domain" http://www.ThreadingBuildingBlocks.org and the previous redirects to http://osstbb.intel.com are being eliminated. Can anyone on the list provide any more information? Or, provide a stable URL that Arun can use for building his FreeBSD TBB port? Thanks, Kevin ----------------------------------------- On Wed, 24 Oct 2007 18:31:47 -0700 "Arun Sharma" <ads...@us...> wrote: > A few weeks ago I sent a patch to make TBB compile on FreeBSD. > Can anyone comment on the status of the patch? > > I also contributed a FreeBSD port: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/tbb > > which included a URL to download TBB and patch for FreeBSD: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/tbb/Makefile?rev=1.1 > > The URL was: > > http://osstbb.intel.com/uploads/76/74/2.0/ > > But sometime in the last few days, the URL seems to have changed to: > > http://threadingbuildingblocks.org/download_file.php?file=uploads/76/74/2.0/tbb20_20070815oss_lin.tar.gz > > which is breaking the build: > > http://portsmon.freebsd.org/portoverview.py?category=devel&portname=tbb > > Is there a URL to the source that is going to be stable? > > The patch in question is also available from: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/tbb/files/patch-freebsd?rev=1.1 > > -Arun > > -- Kevin Farnham O'Reilly Media, TBB Open Source Community http://www.ThreadingBuildingBlocks.org Mailing Lists: http://sourceforge.net/mail/?group_id=200923 FreeNode.net IRC Network: #tbb |
|
From: Arun S. <ads...@us...> - 2007-10-25 01:31:44
|
A few weeks ago I sent a patch to make TBB compile on FreeBSD. Can anyone comment on the status of the patch? I also contributed a FreeBSD port: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/tbb which included a URL to download TBB and patch for FreeBSD: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/tbb/Makefile?rev=1.1 The URL was: http://osstbb.intel.com/uploads/76/74/2.0/ But sometime in the last few days, the URL seems to have changed to: http://threadingbuildingblocks.org/download_file.php?file=uploads/76/74/2.0/tbb20_20070815oss_lin.tar.gz which is breaking the build: http://portsmon.freebsd.org/portoverview.py?category=devel&portname=tbb Is there a URL to the source that is going to be stable? The patch in question is also available from: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/tbb/files/patch-freebsd?rev=1.1 -Arun |
|
From: Adrien G. <aj....@gm...> - 2007-10-19 17:31:13
|
Hey, I've had more time to think on this, and have been looking at parallel blocking I/O. I've changed my mind, I now think that TBB should have some form of blocking I/O handling. I think the task based approach will work as well (leading to I/O tasks and algorithmic tasks), although I do believe that TBB should aim to expose some low-level details of threads so that it could be a universal threading package, without using current TBB constructs. I think that "blocking" tasks (algorithmic ones) in the task scheduler would lead to greater complexity for TBB, but could be useful (at least for me :-) ). So far as implementation, one possibility is to have a worker thread spawned specifically for monitoring I/O. Such a thread would basically accumulate file descriptors that TBB wants to use for I/O, and use say poll() (on POSIX systems) to monitor for availability (and hence be blocked normally, although it could be done without an additional thread too). When I/O is possible, perhaps a special type of task will be spawned to deal with that I/O, which can be scheduled like other tasks. I'm not sure how to ensure that open file descriptors are shared between worker threads on all operating systems. I'm not a threading expert, so I might be speaking nonsense but I'd be interested to hear what everyone thinks. AJ |
|
From: Adrien G. <aj....@gm...> - 2007-10-15 16:13:07
|
Hi Arch, I have thought on this problem. When designing my simulation engine I encountered a problem with TBB not providing the ability to block tasks. My solution basically implemented a method which mapped objects to tasks, and those objects could be "blocked" by having a boolean flag within set appropriately. In my case, if blocking tasks were provided by TBB my solution could be more elegant... but I think that the complexity which would be added to TBB could be fairly substantial. However if TBB's scheduler had the ability to block tasks and to unblock tasks then I would be happy, but I'm not sure who else would benefit :-) (Here I don't mean blocking I/O, but rather a kind of blocked "state" of a task) For blocking I/O, I think that TBB should not provide facilities for it. Realistically if the ability for tasks to have blocking I/O are provided, we are back at a thread model. In my opinion, what is lacking is low level threading interfaces, which could be bundled with TBB to provide access to raw thread constructs. This would allow the developers who need the full features of threads to access them without using the task approach, or resorting to other implementations (it would be handy to use a single package and interface for all cross-platform threading needs). Thus TBB would be capable of both giving a thread-centric and a task-centric view of the world. TBB is really useful as it is, and I think attempting to make TBB into a full thread package will both inflate the code, and dilute the power of TBB. It's my suggestion that other facilities be provided on the side which don't interfere with the task view of the world. AJ On 10/12/07, Robison, Arch <arc...@in... > wrote: > > 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. > > > > 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. > > > > - Arch > > |
|
From: <ste...@te...> - 2007-10-12 20:01:41
|
I will be out of the office starting 10/08/2007 and will not return until 10/15/2007. I will respond to your message when I return. |
|
From: Robison, A. <arc...@in...> - 2007-10-12 19:00:00
|
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 |
|
From: Adrien G. <aj....@gm...> - 2007-10-12 12:26:32
|
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? Thanks! AJ |
|
From: Robison, A. <arc...@in...> - 2007-10-03 21:04:15
|
The only new functionality is blocked_range3d. The rest is mostly a
change in platform support, and removing pesky warnings.
=20
Summary of OS coverage changes:
Linux versions added:
Asianux 3
Debian 4.0 (covered at 2.0 Gold launch)
Fedora Core 6
Fedora 7
Turbo Linux 11
Ubuntu 7.04 (covered at 2.0 Gold launch)
Linux versions dropped=20
Dropped by removing binaries:
Fedora Core 4
Dropped by removing official support; existing binaries
should still work with these:
Asianux 2
Haansoft Linux 2006 Server
Mandriva/Mandrake 10.1
Miracle Linux 4.0
Red Flag DC Server 5.0
Mac OS now only supports base of 10.4.9 (and forward) and Xcode
2.4.1 (and forward); earlier OS revs and Xcode were dropped
=20
Changes in the engineering bits in this release:
- OS changes (see list above)
- COM installers do not issue warnings on Linux OSs any more and
just try to pick the right binaries and proceed
- OSS code contributions (see list below)
- fix a bunch of warnings again
- other minor changes and development work
=20
OSS contributions are also included in this release:
blocked_range3d
small header guard macro patches
=20
- Arch
=20
=20
|
|
From: Kevin F. <ke...@or...> - 2007-10-02 21:24:14
|
Hi, Can anyone give me a brief description (bullet-style is fine) of the major modifications between Commercial-Aligned TBB20_010 and the new Commercial-Aligned TBB20_014 release that just came out? I'd like to post a blog about this. I'll also look at the code, but a summary of the purpose/intent of the changes would be very helpful for starting out the blog. Thanks, Kevin -- Kevin Farnham O'Reilly Media, TBB Open Source Community http://www.ThreadingBuildingBlocks.org Mailing Lists: http://sourceforge.net/mail/?group_id=200923 FreeNode.net IRC Network: #tbb |
|
From: Arun S. <ar...@sh...> - 2007-09-30 23:10:05
|
On 9/29/07, Mike Meyer <mw...@mi...> wrote: > > Any chance of getting this packaged as a FreeBSD port, which can apply > the patch until it gets rolled into the distributed tarball? I don't > see a TBB port. I just send-pr'ed it. You can also get it from: http://www.sharma-home.net/people/arun/misc/tbb.shar -Arun |
|
From: Mike M. <mw...@mi...> - 2007-09-29 21:22:59
|
On Sat, 29 Sep 2007 08:14:37 -0700 Arun Sharma <aru...@sh...> wrote:
> FreeBSD support - tested on 7.0-CURRENT/amd64.
> Should apply cleanly to tbb20_20070815oss_src.tar.gz.
>
> Signed-off-by: Arun Sharma <aru...@sh...>
>
> diff -r 627751b671bb -r ac2c116b7cee build/common.inc
> --- a/build/common.inc Sat Sep 29 16:18:03 2007 -0700
> +++ b/build/common.inc Sat Sep 29 16:51:17 2007 -0700
Any chance of getting this packaged as a FreeBSD port, which can apply
the patch until it gets rolled into the distributed tarball? I don't
see a TBB port.
<mike
--
Mike Meyer <mw...@mi...> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
|
|
From: Malakhov, A. <ant...@in...> - 2007-09-25 15:58:30
|
The answer about the last changes in tbb::concurrent_vector is posted at TBB discussion forum http://softwarecommunity.intel.com/isn/Community/en-US/forums/2471/ShowF orum.aspx =20 Permanent link to the answer is http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/ 30241110/30241110/ShowThread.aspx#30241110 (Please, join lines of the address if these links are broken) =20 // Anton M. -------------------------------------------------------------------- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation,=20 Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: Malakhov, A. <ant...@in...> - 2007-09-24 17:26:48
|
The answer about the last changes in tbb::concurrent_vector is posted at TBB discussion forum http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/ 30241110/30241110/ShowThread.aspx#30241110 -------------------------------------------------------------------- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation,=20 Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: Kevin F. <ke...@or...> - 2007-09-21 18:30:24
|
I wrote a blog post a few weeks ago about my brief study of the code changes that have occurred between the Commercially Aligned 2.0 010 release and the August 15 development code snapshot. While the Unix 'diff' command certainly lets us see what lines have changed, that doesn't really tell us much about why the lines were changed (unless you already know the TBB code well). I noticed that the largest code modifications / enhancements were in the concurrent_vector code. I'm wondering, can anyone from the TBB development team give us some insight into what is being worked on for concurrent_vectors? I plan to blog about concurrent_vectors soon, so it would be great to know what kind of development is ongoing. Just a brief summary would be great. Thanks Kevin -- Kevin Farnham O'Reilly Media, TBB Open Source Community http://www.ThreadingBuildingBlocks.org |
|
From: Kevin F. <ke...@or...> - 2007-09-05 16:25:53
|
There's a discussion in the TBB Forum that will likely be of interest to many people on the Tbb-develop mailing list. The forum thread is titled "Making Parallel_while Better?" Here's the URL: http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30238204.aspx -- Kevin Farnham O'Reilly Media |
|
From: Robison, A. <arc...@in...> - 2007-08-28 20:19:17
|
Quick introduction: I was the original lead developer for TBB, but as
sidetracked for a year on another project, and then was on sabbatical
this summer. Now I'm back.
=20
TBB's assertions are not as well tested as I like. One solution would
be writing negative tests that fail with an assertion failure, and
writing a test harness that deals with negative tests. But I'd like
something simpler and faster. Hence I'm proposing to add an extension
that allows programs to specify a handler to be invoked when an
assertion fails. There would be a new entry point
set_assertion_handler. The interface would look like this:
=20
namespace tbb {
//! Type for an assertion handler
typedef void(*assertion_handler_type)( const char * filename, int
line, const char * expression, const char * comment );
=20
//! Set assertion handler and return previous value of it. =20
/** A value of 0 denotes the default handler. */
assertion_handler_type set_assertion_handler( assertion_handler_type
new_handler );
=20
//! Process an assertion failure.
/** Normally called from __TBB_ASSERT macro. */
If assertion handler is null, print message for assertion
failure and abort.
Otherwise call the assertion handler. */
void assertion_failure( const char * filename, int line, const char
* expression, const char * comment );
} // namespace tbb
=20
Function assertion_failure is already part of TBB. Tests could use the
new entry point set_assertion_handler so make execution go to their own
handler instead of the default handler. The test's handler could tally
the failure and keep going. E.g., with the new entry point, I can write
a macro TRY_BAD_EXPR(x) that checks that expression x does indeed fail
as expected.
=20
Here's an issue for which I'm interested on people's opinions: Should
assertion_handler_type and set_assertion_handler be in namespace tbb or
namespace tbb::internal? An argument for putting it in tbb is that it
corresponds to assertion_failure (which is public only in the sense we
tell TBB users to put a breakpoint there). An argument for putting
the new entry point in tbb::internal is that it is used to test
__TBB_ASSERT, and the latter is not a public interface. Opinions?
Arch D. Robison Intel Corporation =20
arc...@in... Developer Products Division=20
(217)-403-4240 1906 Fox Drive =20
Champaign IL 61820=20
=20
|
|
From: Kevin F. <ke...@or...> - 2007-08-24 04:39:04
|
test2 |
|
From: Randy D. S. <ran...@gm...> - 2007-08-23 22:16:31
|
Seems to be working. FYI, we appear to have a "reply to author" default
instead of "reply to list". In general, I think a good idea.
I won't reply to the users' list... that test came through fine as well.
--
RDS
On 8/23/07, Kevin Farnham <ke...@or...> wrote:
>
> testing the new TBB develop mail list
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Tbb-develop mailing list
> Tbb...@li...
> https://lists.sourceforge.net/lists/listinfo/tbb-develop
>
|
|
From: Kevin F. <ke...@or...> - 2007-08-23 21:54:25
|
testing the new TBB develop mail list |
2 messages has been excluded from this view by a project administrator.
