Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
17 Views

TBB 3.0 update 2 commercial-aligned release is available

TBB 3.0 update 2commercial-aligned release is available on our open source site.

Changes (w.r.t. TBB 3.0 Update 1 commercial-aligned release):
- Destructor of tbb::task_group class throws missing_wait exception
if there are tasks running when it is invoked.
- Cilk-TBB interop layer added to protect TBB TLS in case of
"Cilk-TBB-Cilk nesting" usage model.
- Compilation fix for dependent template names in concurrent_queue.
- Memory allocator code refactored to ease development and maintenance.
Bug Fixes:
- Improved interoperability with other Intel software tools on Linux in
case of dynamic replacement of memory allocator (1700)
--Vladimir
0 Kudos
6 Replies
Highlighted
Black Belt
17 Views

Missed opportunity... May I assume that my remarks with update 1 will be incorporated in update 3 soon, instead?
0 Kudos
Highlighted
17 Views

Yes, some of those that are rather straightforward. Not the atomics for doubles and probably not Xwindow over ssh.
0 Kudos
Highlighted
Black Belt
17 Views

The load and store specialisations for doubles are quite straightforward, and necessary to pass the tests:
[bash]template<>
inline atomic_impl::operator atomic_impl::value_type() const volatile {
converter w;
w.bits = __TBB_Load8(&rep.value);
return w.value;
}

template<>
inline atomic_impl::value_type atomic_impl::store_with_release( value_type rhs ) {
converter u;
u.value = rhs;
__TBB_Store8(&rep.value,u.bits);
return rhs;
}
[/bash]
I'm not sure yet how to transparently work with X over ssh (other than ad hoc, by automatically setting X_NOSHMEM based on a predefined macro indicating the environment, assuming that the program will always be used that way), but providing a useful diagnostic for mysteriously black video output is simply a matter of adapting xerr_handler() as follows:
[bash]int xerr_handler(Display*, XErrorEvent *error)
{
#ifndef X_NOSHMEM
if (after_apparent_success_for_XShmAttach && X_ShmAttach==error->minor_code)
{
fprintf(stderr,
"Problem detected: try rebuilding with X_NOSHMEM defined in " __FILE__ "n");
}
#endif
x_error = error->error_code;
if(g_video) g_video->running = false;
return 0;
}
[/bash]
with after_apparent_success_for_XShmAttach a static bool set to true right after XShmAttach apparently succeeded with x_error still 0, which is evidently not always a sufficient test, so without a diagnostic one might lose quite some time finding that out...

(Added) Actually, I'm not 100% sure whether this was just something I tried or whether it really printed something... but a note in the porting documentation might fit the bill as well, because it still requires intervention.
0 Kudos
Highlighted
17 Views

I have reworked the atomic 8-byte operations for 4-byte machine word, so might be nothing special is necessary for doubles anymore.

What compiler reported you the bunch of warnings in tachyon, some new or exotic one? I am trying to decide on the best solution for this.

For the X over SSH issue, if you have some working code for error handling could you please contribute it? I cannot take the code above and put it under our copyright.
0 Kudos
Highlighted
Black Belt
17 Views

"I have reworked the atomic 8-byte operations for 4-byte machine word, so might be nothing special is necessary for doubles anymore."
If it's a change between update 1 and update 2, sorry if I missed that? I'll have another look tonight, but with update 1 it didn't work without this change.

"What compiler reported you the bunch of warnings in tachyon, some new or exotic one? I am trying to decide on the best solution for this."
The most recent Ubuntu, actually (10.04 LTS "Lucid Lynx", on x86), so a lot of people should be exposed to that one. I like the idea behind adding the warning, but of course it means trouble for existing code.

"For the X over SSH issue, if you have some working code for error handling could you please contribute it? I cannot take the code above and put it under our copyright."
OK

0 Kudos
Highlighted
17 Views

No the change I mentioned is to appear in the next update.

Sounds like it's GCC 4.5; I will check then, and find how to suppress the warning (presumably with some pragma).
0 Kudos