TBB 3.0 update 2 commercial-aligned release is available

[Vladimir_P_1234567890]

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

[RafSchietekat]

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

[Alexey-Kukanov]

Yes, some of those that are rather straightforward. Not the atomics for doubles and probably not Xwindow over ssh.

[RafSchietekat]

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-Kukanov]

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]

"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-Kukanov]

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).