Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
2401 Discussions

TBB 3.0 update 2 commercial-aligned release is available

Vladimir_P_Intel2
60 Views
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
RafSchietekat
Black Belt
60 Views
Missed opportunity... May I assume that my remarks with update 1 will be incorporated in update 3 soon, instead?
Alexey_K_Intel3
Employee
60 Views
Yes, some of those that are rather straightforward. Not the atomics for doubles and probably not Xwindow over ssh.
RafSchietekat
Black Belt
60 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.
Alexey_K_Intel3
Employee
60 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.
RafSchietekat
Black Belt
60 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

Alexey_K_Intel3
Employee
60 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).
Reply