Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tasks are enqueued but not executed in TBB #86

Closed
Sangarshan opened this issue Sep 8, 2018 · 20 comments
Closed

Tasks are enqueued but not executed in TBB #86

Sangarshan opened this issue Sep 8, 2018 · 20 comments

Comments

@Sangarshan
Copy link

Hi
We are running into TBB scheduler issue where we see tasks are getting enqueued but not executed.
we see same issue with both TBB version: TBB 2018 Update 5 and TBB 4.3 initial version.
In our application, aster thread instantiates Scheduler with thread count as 8. priority is same for all tasks. and tbb::task::enqueue() method is used for enqueuing task. we use one tbb worker thread for i/o and it runs forever.
in current state, number of active threads in arena is 1 and which is used for i/o . as per the TBB state , new work is available and my_max_workers_requested is 8 but server my slack value is set to -1, all worker threads ( except one used for i/o) are in commit wait state waiting for wake up signal. it never recovered from this state. can you please share some details on what could be wrong.

Arena object elements:
my_task_stream = {tbb::internal::no_copy = {tbb::internal::no_assign = {}, }, population = {0, 26300, 0}, lanes = {0x3169e68,

        0x3177b38, 0x317a948}, N = 16}, my_max_num_workers = 8, my_num_workers_requested = 8,

    my_pool_state = {<tbb::internal::atomic_impl_with_arithmetic<unsigned long, unsigned long, char>> = {<tbb::internal::atomic_impl<unsigned long>> = {my_storage = {

            my_value = 18446744073709551615}}, <No data fields>}, <No data fields>},

Thanks in advance,
Sangarshan
@Sangarshan
Copy link
Author

Sangarshan commented Sep 10, 2018 •
edited
Loading

we see a loop in asleep_list in private server object.
total 256 workers created , looks like linked list is broken. we see loop as given below with worker index
241->250->245->249->246->251->244->251
worker 244 is pointing back to 251 here.

@Sangarshan
Copy link
Author

@tbbdev, @akukanov, can you please respond

@ntfshard
Copy link

Hello

Did you try to reproduce it with a newer versions of the library? Could you please provide a reproducer.

@Sangarshan
Copy link
Author

Sangarshan commented Sep 12, 2018 via email

@alexey-katranov
Copy link
Contributor

@ntfshard, the issue is reproduced with TBB 2018 Update 5. I would not expect much difference with TBB 2019.
@Sangarshan, we failed to figure out how it could happen. The asleep_list is used only under the lock and the logic is quite primitive. We even supposed that some memory barriers could be broken but there were a lot of other places where it could reveal some other issues. So, it will be great if you can share a core file with us. Is it big?
What is your hardware and software configuration (CPU and OS)?

@Sangarshan
Copy link
Author

Sangarshan commented Sep 12, 2018 via email

@Sangarshan
Copy link
Author

Sangarshan commented Sep 12, 2018 via email

@ananth-at-camphor-networks
Copy link

ananth-at-camphor-networks commented Sep 12, 2018 •
edited
Loading

This is the fix that we propose (Please ignore the counters we have used for debugging purposes only)

diff --git a/src/rml/server/thread_monitor.h b/src/rml/server/thread_monitor.h
index 4ddd5bf..a10aec1 100644
--- a/src/rml/server/thread_monitor.h
+++ b/src/rml/server/thread_monitor.h
@@ -78,7 +78,7 @@ public:
         friend class thread_monitor;
         tbb::atomic<size_t> my_epoch;
     };
-    thread_monitor() : spurious(false), my_sema() {
+    thread_monitor() : spurious(false), my_sema(), notify_count(0) {
         my_cookie.my_epoch = 0;
         ITT_SYNC_CREATE(&my_sema, SyncType_RML, SyncObj_ThreadMonitor);
         in_wait = false;
@@ -133,6 +133,7 @@ private:
     tbb::atomic<bool>   in_wait;
     bool   spurious;
     tbb::internal::binary_semaphore my_sema;
+     int notify_count;
 #if USE_PTHREAD
     static void check( int error_code, const char* routine );
 #endif
@@ -240,6 +241,7 @@ inline void thread_monitor::notify() {
     my_cookie.my_epoch = my_cookie.my_epoch + 1;
     bool do_signal = in_wait.fetch_and_store( false );
     if( do_signal )
+        notify_count++;
         my_sema.V();
 }
 
diff --git a/src/tbb/private_server.cpp b/src/tbb/private_server.cpp
index ae25e57..2ef0da1 100644
--- a/src/tbb/private_server.cpp
+++ b/src/tbb/private_server.cpp
@@ -25,7 +25,7 @@
 #include "scheduler_common.h"
 #include "governor.h"
 #include "tbb_misc.h"
-
+#include <cassert>
 using rml::internal::thread_monitor;
 
 namespace tbb {
@@ -76,6 +76,13 @@ private:
 
     //! Link for list of workers that are sleeping or have no associated thread.
     private_worker* my_next;
+    private_worker* my_prev;
+
+    //Should be one , if it is two or more , then it was like like woken up,no job,sleep again;
+    int wait_count;
+
+    // number of times worker went to commit wait, this is compared with notify count
+    int sleep_count;
 
     friend class private_server;
 
@@ -95,7 +102,8 @@ private:
 protected:
     private_worker( private_server& server, tbb_client& client, const size_t i ) :
         my_server(server), my_client(client), my_index(i),
-        my_thread_monitor(), my_handle(), my_next()
+        my_thread_monitor(), my_handle(), my_next(NULL), my_prev(NULL),
+        wait_count(0), sleep_count(0)
     {
         my_state = st_init;
     }
@@ -135,6 +143,7 @@ private:
         Can be lowered asynchronously, but must be raised only while holding my_asleep_list_mutex,
         because raising it impacts the invariant for sleeping threads. */
     atomic<int> my_slack;
+    atomic<int> sleep_list_loop_count;
 
     //! Counter used to determine when to delete this.
     atomic<int> my_ref_count;
@@ -267,13 +276,16 @@ void private_worker::run() {
     ::rml::job& j = *my_client.create_one_job();
     while( my_state!=st_quit ) {
         if( my_server.my_slack>=0 ) {
+            wait_count = 0;
             my_client.process(j);
         } else {
+            wait_count++;
             thread_monitor::cookie c;
             // Prepare to wait
             my_thread_monitor.prepare_wait(c);
             // Check/set the invariant for sleeping
             if( my_state!=st_quit && my_server.try_insert_in_asleep_list(*this) ) {
+                sleep_count++;
                 my_thread_monitor.commit_wait(c);
                 my_server.propagate_chain_reaction();
             } else {
@@ -328,11 +340,14 @@ private_server::private_server( tbb_client& client ) :
 #if TBB_USE_ASSERT
     my_net_slack_requests = 0;
 #endif /* TBB_USE_ASSERT */
+    sleep_list_loop_count = 0;
     my_asleep_list_root = NULL;
     my_thread_array = tbb::cache_aligned_allocator<padded_private_worker>().allocate( my_n_thread );
     for( size_t i=0; i<my_n_thread; ++i ) {
         private_worker* t = new( &my_thread_array[i] ) padded_private_worker( *this, client, i );
         t->my_next = my_asleep_list_root;
+        if (my_asleep_list_root)
+            my_asleep_list_root->my_prev = t;
         my_asleep_list_root = t;
     }
 }
@@ -353,7 +368,14 @@ inline bool private_server::try_insert_in_asleep_list( private_worker& t ) {
     // it sees us sleeping on the list and wakes us up.
     int k = ++my_slack;
     if( k<=0 ) {
+        if (t.my_next || t.my_prev || &t == my_asleep_list_root) {
+            ++sleep_list_loop_count;
+            --my_slack;
+            return true;
+        }
         t.my_next = my_asleep_list_root;
+        if (my_asleep_list_root)
+            my_asleep_list_root->my_prev = &t;
         my_asleep_list_root = &t;
         return true;
     } else {
@@ -383,6 +405,10 @@ void private_server::wake_some( int additional_slack ) {
             }
             // Pop sleeping worker to combine with claimed unit of slack
             my_asleep_list_root = (*w++ = my_asleep_list_root)->my_next;
+            assert(!(*(w-1))->my_prev);
+            if (my_asleep_list_root)
+                my_asleep_list_root->my_prev = NULL;
+            (*(w-1))->my_next = NULL;
         }
         if( additional_slack ) {
             // Contribute our unused slack to my_slack.
diff --git a/src/tbb/semaphore.h b/src/tbb/semaphore.h
index e80e931..3dad60e 100644
--- a/src/tbb/semaphore.h
+++ b/src/tbb/semaphore.h
@@ -210,7 +210,7 @@ public:
     }
     //! post/release
     void V() {
-        __TBB_ASSERT( my_sem>=1, "multiple V()'s in a row?" );
+        // __TBB_ASSERT( my_sem>=1, "multiple V()'s in a row?" );
         if( my_sem--!=1 ) {
             //if old value was 2
             my_sem = 0;

@ananth-at-camphor-networks
Copy link

Related information in here https://en.wikipedia.org/wiki/Spurious_wakeup

@alexey-katranov
Copy link
Contributor

It looks like I could reproduce the situation when a worker thread was active while remaining in the asleep list. I am not sure if it relates to the spurious wakeup issue because my reproducer fails on Windows as well (or maybe something else is broken). Moreover, the underlying sync primitives are protected from spurious wake up (e.g. semaphore.h:205). In addition, the spurious wakeup issue usually relates to condition variables (not semaphores). I will continue investigation and notify you if I can figure out something.

@ananth-at-camphor-networks
Copy link

Thanks Alexey. I see some comments though, in the code which allude to spurious wakeups such as in thread_monitor.h:215 in thread_monitor::prepare_wait as
// consumes a spurious posted signal. don't wait on my_sema.

In any case, I am glad that you are also able to reproduce the situation where in the sleep list gets corrupted (or becomes circular) and then gets into bad state.

Please let us know if you can find the real reason how we can get into that state where a thread becomes active when it is suppose to be sleeping. Irrespective, if we want to handle such a situation, we have done the following. Do you see any issue with this approach of making the list as doubly linked and then checking before inserting into the list ? If the worker is already present in the list, we just restore my_slack and return true. Caller behaves as if the worker was indeed inserted into the sleep list.

@@ -353,7 +368,14 @@ inline bool private_server::try_insert_in_asleep_list( private_worker& t ) {
     // it sees us sleeping on the list and wakes us up.
     int k = ++my_slack;
     if( k<=0 ) {
+        if (t.my_next || t.my_prev || &t == my_asleep_list_root) {
+            ++sleep_list_loop_count;
+            --my_slack;
+            return true;
+        }
         t.my_next = my_asleep_list_root;
+        if (my_asleep_list_root)
+            my_asleep_list_root->my_prev = &t;
         my_asleep_list_root = &t;
         return true;
     } else {

Thanks

@alexey-katranov
Copy link
Contributor

alexey-katranov commented Sep 17, 2018 •
edited
Loading

It looks like that I observed inconsistent state of the asleep_list only during shutdown (that is not an issue). Unfortunately, I was unable to reproduce the issue during working phase of any of my tests. Could you, please, assist us to get more information about your use case?

  • Could you share the core file? Is there confidential information? I can try to ask Intel representative to organize secure file transfer if necessary.
  • Could you describe your application in a few words? What TBB interfaces are used? Do you create/destroy your own threads (that are using TBB). What is high level algorithm structure?
  • Are you using the prebuilt TBB version or rebuilding it manually?

As for workaround, perhaps, it will work but while we do not know the root cause, it can only hide some symptoms (are we sure about other side effects?).

@ananth-at-camphor-networks
Copy link

Hi,

Thanks for looking into this.

  1. We only use tbb:task_scheduler_init() constructor at the beginning and tbb_task_enqeueue() method to enqueue tasks
  2. We were not building tbb ourselves for most platforms. But for some such as for redhat, we do build but without any modification until now
  3. FWIW, here is our code where we call into tbb https://github.com/Juniper/contrail-controller/blob/R3.2.3.x/src/base/task.cc
  4. Binary, library, core file and diff (with which we confirm that duplicate insert into the sleep list did happen) are available here.
    https://drive.google.com/file/d/13LSgIIrLMkM4RdPYJ6s-BG79SINseo_0/view?usp=sharing

My email in case you want to reach out to me directly is
[email protected] and [email protected]

Thanks once again. I really appreciate it.

@ananth-at-camphor-networks
Copy link

And Sangarshan can be reached at [email protected]

@ananth-at-camphor-networks
Copy link

Just to further clarify, in our testing, we do hit the condition of duplicate insertion (very rarely though), and when it does, fix takes effect and the daemon continues to function normally, afaik.

opencontrail-ci-admin pushed a commit to Juniper/contrail-third-party that referenced this issue Sep 21, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
92489e3 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Closes-Bug: #1684993
Change-Id: I6773eb8dddd849cebb695a59864a9da2ce2faa17
Depends-On: Iec821e3b08c3825cf2789a70bf53621650c66516
opencontrail-ci-admin pushed a commit to Juniper/contrail-third-party that referenced this issue Sep 24, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
5cf3f4c 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Closes-Bug: #1684993
Change-Id: I6773eb8dddd849cebb695a59864a9da2ce2faa17
Depends-On: Iec821e3b08c3825cf2789a70bf53621650c66516
opencontrail-ci-admin pushed a commit to Juniper/contrail-controller that referenced this issue Sep 24, 2018
@ananth-at-camphor-networks @vmahuli
Do not insert already sleeping tbb task back into sleeping list
5095a90 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: I3375b8be324245c329a9bd3a1f001a38576f617d
Closes-Bug: #1684993
opencontrail-ci-admin pushed a commit to Juniper/contrail-third-party that referenced this issue Sep 26, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
ddc576e 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: Ie5de2844a19843bec185e921a83bde4f55c1b6ed
Closes-Bug: #1684993
opencontrail-ci-admin pushed a commit to Juniper/contrail-controller that referenced this issue Sep 26, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
f770d34 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: I052d397bf8b881c75e9ed6a8d17e7cbc1b12764b
Closes-Bug: #1684993
Depends-On: Ie5de2844a19843bec185e921a83bde4f55c1b6ed
opencontrail-ci-admin pushed a commit to Juniper/contrail-controller that referenced this issue Sep 26, 2018
@ananth-at-camphor-networks @vmahuli
Do not insert already sleeping tbb task back into sleeping list
586ecf4 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: I3375b8be324245c329a9bd3a1f001a38576f617d
Closes-Bug: #1684993
opencontrail-ci-admin pushed a commit to Juniper/contrail-third-party that referenced this issue Oct 1, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
c0c55a5 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: I84993a23b4524f19c42e4166015c9216466c6865
Closes-Bug: #1684993
opencontrail-ci-admin pushed a commit to Juniper/contrail-controller that referenced this issue Oct 1, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
8542634 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: I1c08787cf74a12b5486189eb0dc69cd524ed4170
Closes-Bug: #1684993
Depends-On: I84993a23b4524f19c42e4166015c9216466c6865
opencontrail-ci-admin pushed a commit to Juniper/contrail-third-party-cache that referenced this issue Oct 1, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
2bc86f2 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: Ic0a943b54afa07115ad6f304310d385cb199c504
Closes-Bug: #1684993
Depends-On: I1c08787cf74a12b5486189eb0dc69cd524ed4170
Depends-On: I84993a23b4524f19c42e4166015c9216466c6865
@akukanov
Copy link
Contributor

akukanov commented Oct 4, 2018

@Rombie, since you said above that you rebuild the TBB library for RedHat Linux: could you try the original TBB binaries from our packages? And when you rebuild, do you use the makefiles provided with TBB, or your own build system? Also please specify the compiler and any special command line options, so that we can try to reproduce the issue with the same compilation settings.

@ananth-at-camphor-networks
Copy link

ananth-at-camphor-networks commented Oct 9, 2018 •
edited
Loading

Sorry. I did not realize that you posted a response to this. Some how, I don't get an email indicating some activity on this issue. Anyways, thanks once again for your kind support!

We build tbb for different OS distributions including RedHat. In this particular case, we used CentOS 7. Yes, we do use the makefiles provided by the TBB library as is and pretty much just do make.

https://github.com/Juniper/contrail-controller/blob/master/lib/tbb/SConscript#L28

We do not use any special flag to while running make, as you can see in line number 28 in the link provided above. We just do make from the top level.

Compiler is gcc as provided with CentOS 7 based. I don't have that system available as it has been re-imaged.

IIRC, We had seen this tbb issue in ubuntu too. (But that was years ago)

Did you get a chance to open and analyze the core file from here, where duplicate insertion into the list was clearly caught using assert that we added during our testing ?

https://drive.google.com/file/d/13LSgIIrLMkM4RdPYJ6s-BG79SINseo_0/view?usp=sharing

Thanks so much once again! Please feel free to email me directly as well [email protected] or [email protected] if you need any additional information.

@ananth-at-camphor-networks
Copy link

Btw, just to be clear, we always used the binaries directly as provided in the distribution upstream. In order to use our proposed fix, we now build and distribute libtbb.so.2 from within our rpms.

opencontrail-ci-admin pushed a commit to Juniper/contrail-packages that referenced this issue Oct 16, 2018
@ananth-at-camphor-networks @npchandran
Do not insert already sleeping tbb task back into sleeping list
8f588c9 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

With this change, libtbb.so.2 is provided directly from contrail-lib
package.

Change-Id: I07416601cd9be658d75309caa0917d3c61d9e427
Closes-Bug: #1684993
@akukanov
Copy link
Contributor

In TBB 2019 Update 2, we strengthened the code in private_server.cpp to better maintain and check the asleep list invariants. You can check the changes here: 8ff3697#diff-2a516a05e707d67f7033228864830164

In our testing, we do not observe spurious wakeups or failed assertions. Moreover, we believe the code in semaphore.h that implements binary_semaphore (which is used for sleeping in thread_monitor) is protected from spurious wakeups. For example, for futex-based implementation https://github.com/01org/tbb/blob/8ff3697f544c5a8728146b70ae3a978025be1f3e/src/tbb/semaphore.h#L201-L212 the loop at lines 207-210 obtains the semaphore counter value via fetch_and_store and only exits waiting if the counter was set to 0, which can only be done when the semaphore is signaled.

Could you please check if this latest TBB update works in your environment?

opencontrail-ci-admin pushed a commit to Juniper/contrail-third-party that referenced this issue Nov 29, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
43fba6a 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

Change-Id: I79bcd7192ea7c7db732b191503d0747e4b0ff229
Closes-Bug: #1684993
opencontrail-ci-admin pushed a commit to Juniper/contrail-controller that referenced this issue Nov 29, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
d3512f4 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

Also take commit db50e81 to fix build with
newer TBB.

uxlfoundation/oneTBB#86

Change-Id: I83a7d267d4558c02715c675db5fc08f58f1208e2
Depends-On: I79bcd7192ea7c7db732b191503d0747e4b0ff229
Closes-Bug: #1684993
opencontrail-ci-admin pushed a commit to Juniper/contrail-packages that referenced this issue Nov 29, 2018
@ananth-at-camphor-networks
Do not insert already sleeping tbb task back into sleeping list
285925d 
During testing, it was found that tbb sleeping threads singly linked
list was corrupted and had become circular. This seemingly caused
my_slack count to get permanently stuck at -1, as the sleeping list
traversal would potentially never end.

During testing, using a specific assert, it was confirmed that duplicate
insertion did happen.

Fixed it by modifying the sleeing threads singly linked list into a
doubly linked list and then making sure that a thread if already in
the list is never prepended back as the head of the list.

uxlfoundation/oneTBB#86

With this change, libtbb.so.2 is provided directly from contrail-lib
package.

Change-Id: I4b911de240544143ad1833641ffe640155a34648
Depends-On: I83a7d267d4558c02715c675db5fc08f58f1208e2
Closes-Bug: #1684993
@lzhangzz lzhangzz mentioned this issue Feb 25, 2020
Closed
@aleksei-fedotov
Copy link
Contributor

Since there is no relevant activity for quite a long time, I propose closing the issue. Interested people could always reopen it if they deem useful.

@tbbdev tbbdev closed this as completed Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@ananth-at-camphor-networks @ntfshard @aleksei-fedotov @tbbdev @alexey-katranov @akukanov @Sangarshan