You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by CrazyCow <zh...@gmail.com> on 2017/09/29 00:55:53 UTC
[Dependency Proposal] intel::tbb
Hi, ATS devs,
Currently, we have a requirement of concurrent_unordered_map (details can
be found https://github.com/apache/trafficserver/pull/2555). And
intel::tbb::concurrent_unordered_map is the most mature one we can try out.
I understand this dependency is huge. I'd like to hear opinions from you
guys, that whether we need to do it or not and if yes, what is the best
approach to introduce it.
Thanks,
Zizhong
Re: [Dependency Proposal] intel::tbb
Posted by CrazyCow <zh...@gmail.com>.
Seems the latest version supports FreeBSD and SunOS.
https://github.com/01org/tbb/blob/tbb_2018/build/FreeBSD.inc
https://github.com/01org/tbb/blob/tbb_2018/build/SunOS.inc
2017-09-29 8:26 GMT-07:00 James Peach <jp...@apache.org>:
>
> > On Sep 29, 2017, at 7:37 AM, Derek Dagit <de...@oath.com.INVALID>
> wrote:
> >
> > 3) Does it run on platforms that are supported by ATS, like FreeBSD? I
> > thought there was not official support without patching it, but not
> > sure.
>
> https://www.threadingbuildingblocks.org/system-requirements
>
> AFAICT they claim x86-only and don't (officially) support *BSD or Solaris.
>
> >
> > On Thu, Sep 28, 2017 at 7:58 PM, Alan Carroll
> > <so...@oath.com.invalid> wrote:
> >> There are two big issues for me:
> >>
> >> 1) What level of use will we have in the rest of the ATS core? It's a
> big
> >> chunk for just one place in the core. If that were it, I'd be more
> tempted
> >> to port the equivalent container from Concurrency Kit which would have a
> >> much smaller footprint.
> >> 2) How stable is this? I've heard claims TBB is expected to be the base
> for
> >> the next generation of STL parallel containers. Is that true? Does
> anyone
> >> actually know?
> >
> >
> >
> > --
> > Derek
>
>
Re: [Dependency Proposal] intel::tbb
Posted by James Peach <jp...@apache.org>.
> On Sep 29, 2017, at 7:37 AM, Derek Dagit <de...@oath.com.INVALID> wrote:
>
> 3) Does it run on platforms that are supported by ATS, like FreeBSD? I
> thought there was not official support without patching it, but not
> sure.
https://www.threadingbuildingblocks.org/system-requirements
AFAICT they claim x86-only and don't (officially) support *BSD or Solaris.
>
> On Thu, Sep 28, 2017 at 7:58 PM, Alan Carroll
> <so...@oath.com.invalid> wrote:
>> There are two big issues for me:
>>
>> 1) What level of use will we have in the rest of the ATS core? It's a big
>> chunk for just one place in the core. If that were it, I'd be more tempted
>> to port the equivalent container from Concurrency Kit which would have a
>> much smaller footprint.
>> 2) How stable is this? I've heard claims TBB is expected to be the base for
>> the next generation of STL parallel containers. Is that true? Does anyone
>> actually know?
>
>
>
> --
> Derek
Re: [Dependency Proposal] intel::tbb
Posted by Derek Dagit <de...@oath.com.INVALID>.
3) Does it run on platforms that are supported by ATS, like FreeBSD? I
thought there was not official support without patching it, but not
sure.
On Thu, Sep 28, 2017 at 7:58 PM, Alan Carroll
<so...@oath.com.invalid> wrote:
> There are two big issues for me:
>
> 1) What level of use will we have in the rest of the ATS core? It's a big
> chunk for just one place in the core. If that were it, I'd be more tempted
> to port the equivalent container from Concurrency Kit which would have a
> much smaller footprint.
> 2) How stable is this? I've heard claims TBB is expected to be the base for
> the next generation of STL parallel containers. Is that true? Does anyone
> actually know?
--
Derek
Re: [Dependency Proposal] intel::tbb
Posted by Alan Carroll <so...@oath.com.INVALID>.
There are two big issues for me:
1) What level of use will we have in the rest of the ATS core? It's a big
chunk for just one place in the core. If that were it, I'd be more tempted
to port the equivalent container from Concurrency Kit which would have a
much smaller footprint.
2) How stable is this? I've heard claims TBB is expected to be the base for
the next generation of STL parallel containers. Is that true? Does anyone
actually know?
Re: [Dependency Proposal] intel::tbb
Posted by Masaori Koshiba <ma...@apache.org>.
Anybody looked at libcds[1]? It says it's mostly header-only template
library of concurrent data structures. It sounds like what we're looking
for. And performance looks similar to TBB.
( I'm not -1 to TBB )
- [1] libcds
https://github.com/khizmax/libcds
- Masaori
2017年10月5日(木) 7:37 Jason Kenny <jk...@oath.com.invalid>:
> I this we could a lot of value out of TBB. The tasking engine is much
> better than what we have. However I would not suggest we just replace
> everything, but instead bring it in and look at "low-hanging" fruit such as
> the hash map that we can get value out of today. Larger projects as using
> its advance tasking engine, arena, etc can be done slowing as the team
> understands the value in doing so and how to do it without breaking
> existing APIs.
>
> On Wed, Oct 4, 2017 at 3:59 PM, CrazyCow <zh...@gmail.com>
> wrote:
>
> > We use continuations everywhere, which might not be appropriate according
> > to the above quote? xD
> >
> > For this particular use case of the PR, it's pretty simple code and I
> don't
> > think it will be a performance bottleneck. What we want here is a mature,
> > well documented and widely used concurrent implementation of hashmap,
> which
> > I think tbb is one of the top choices.
> >
> > 2017-10-01 15:04 GMT-07:00 Alan Carroll <solidwallofcode@oath.com.
> > invalid>:
> >
> > > I wonder where Concurrency Kit falls on that graph. Here's an
> interesting
> > > quote from TBB:[1]
> > >
> > > "Using the task scheduler is usually the best approach to threading for
> > > performance, however there are cases when the task scheduler is not
> > > appropriate. The task scheduler is intended for high-performance
> > algorithms
> > > composed from non-blocking tasks. It still works if the tasks rarely
> > block.
> > > However, if threads block frequently, there is a performance loss when
> > > using the task scheduler because while the thread is blocked, it is not
> > > working on any tasks. Blocking typically occurs while waiting for I/O
> or
> > > mutexes for long periods. If threads hold mutexes for long periods,
> your
> > > code is not likely to perform well anyway, no matter how many threads
> it
> > > has. If you have blocking tasks, it is best to use full-blown threads
> for
> > > those."
> > >
> > > Hmmmm.....
> > >
> > > [1] https://software.intel.com/en-us/node/506101
> > >
> >
>
Re: [Dependency Proposal] intel::tbb
Posted by Jason Kenny <jk...@oath.com.INVALID>.
I this we could a lot of value out of TBB. The tasking engine is much
better than what we have. However I would not suggest we just replace
everything, but instead bring it in and look at "low-hanging" fruit such as
the hash map that we can get value out of today. Larger projects as using
its advance tasking engine, arena, etc can be done slowing as the team
understands the value in doing so and how to do it without breaking
existing APIs.
On Wed, Oct 4, 2017 at 3:59 PM, CrazyCow <zh...@gmail.com> wrote:
> We use continuations everywhere, which might not be appropriate according
> to the above quote? xD
>
> For this particular use case of the PR, it's pretty simple code and I don't
> think it will be a performance bottleneck. What we want here is a mature,
> well documented and widely used concurrent implementation of hashmap, which
> I think tbb is one of the top choices.
>
> 2017-10-01 15:04 GMT-07:00 Alan Carroll <solidwallofcode@oath.com.
> invalid>:
>
> > I wonder where Concurrency Kit falls on that graph. Here's an interesting
> > quote from TBB:[1]
> >
> > "Using the task scheduler is usually the best approach to threading for
> > performance, however there are cases when the task scheduler is not
> > appropriate. The task scheduler is intended for high-performance
> algorithms
> > composed from non-blocking tasks. It still works if the tasks rarely
> block.
> > However, if threads block frequently, there is a performance loss when
> > using the task scheduler because while the thread is blocked, it is not
> > working on any tasks. Blocking typically occurs while waiting for I/O or
> > mutexes for long periods. If threads hold mutexes for long periods, your
> > code is not likely to perform well anyway, no matter how many threads it
> > has. If you have blocking tasks, it is best to use full-blown threads for
> > those."
> >
> > Hmmmm.....
> >
> > [1] https://software.intel.com/en-us/node/506101
> >
>
Re: [Dependency Proposal] intel::tbb
Posted by CrazyCow <zh...@gmail.com>.
We use continuations everywhere, which might not be appropriate according
to the above quote? xD
For this particular use case of the PR, it's pretty simple code and I don't
think it will be a performance bottleneck. What we want here is a mature,
well documented and widely used concurrent implementation of hashmap, which
I think tbb is one of the top choices.
2017-10-01 15:04 GMT-07:00 Alan Carroll <so...@oath.com.invalid>:
> I wonder where Concurrency Kit falls on that graph. Here's an interesting
> quote from TBB:[1]
>
> "Using the task scheduler is usually the best approach to threading for
> performance, however there are cases when the task scheduler is not
> appropriate. The task scheduler is intended for high-performance algorithms
> composed from non-blocking tasks. It still works if the tasks rarely block.
> However, if threads block frequently, there is a performance loss when
> using the task scheduler because while the thread is blocked, it is not
> working on any tasks. Blocking typically occurs while waiting for I/O or
> mutexes for long periods. If threads hold mutexes for long periods, your
> code is not likely to perform well anyway, no matter how many threads it
> has. If you have blocking tasks, it is best to use full-blown threads for
> those."
>
> Hmmmm.....
>
> [1] https://software.intel.com/en-us/node/506101
>
Re: [Dependency Proposal] intel::tbb
Posted by Alan Carroll <so...@oath.com.INVALID>.
I wonder where Concurrency Kit falls on that graph. Here's an interesting
quote from TBB:[1]
"Using the task scheduler is usually the best approach to threading for
performance, however there are cases when the task scheduler is not
appropriate. The task scheduler is intended for high-performance algorithms
composed from non-blocking tasks. It still works if the tasks rarely block.
However, if threads block frequently, there is a performance loss when
using the task scheduler because while the thread is blocked, it is not
working on any tasks. Blocking typically occurs while waiting for I/O or
mutexes for long periods. If threads hold mutexes for long periods, your
code is not likely to perform well anyway, no matter how many threads it
has. If you have blocking tasks, it is best to use full-blown threads for
those."
Hmmmm.....
[1] https://software.intel.com/en-us/node/506101
Re: [Dependency Proposal] intel::tbb
Posted by CrazyCow <zh...@gmail.com>.
Yea, I looked into Junction before tbb, until I found this comment on
hacker news.
Uhm... The absolute Y-position of the curve on the graph is secondary to
> its shape. Also, the scalability discussion is largely pointless if the
> sample set covers only 6 CPUs.
> Intel TBB scales proportionally, which is precisely what you'd want here.
> Junction starts to flatten out on 6th CPU, which implies that it has
> fundamental design issues that crop up at higher CPU counts. Chances are
> that its performance not only won't scale further, but will actually drop
> further down the graph.
> On other hand TBB code can be put throught some routine code optimization
> (hand-coded assembly and such) to increase its performance without
> affecting its linear graph shape.
From https://news.ycombinator.com/item?id=11016350
And at the end of the blog you mentioned, the author admitted Junction was
a temporary project, so I walked away.
> Jeff Preshing · 16 weeks ago
> Look like I didn't implement that, sorry! I know clear is basic
> functionality, but this was an experimental project and I'm now busy with
> other things. I suppose there are different ways it could be added
> depending whether thread safety is required.
2017-09-29 15:13 GMT-07:00 Bryan Call <bc...@apache.org>:
> Here are some benchmark numbers I ran across when looking at different
> thread safe hash implementations:
>
>
>
>
> Source: http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/
>
> -Bryan
>
>
>
> On Sep 29, 2017, at 2:42 PM, Bryan Call <bc...@apache.org> wrote:
>
> TCL handles concurrency for memory allocation bits. Looking at it more,
> the hashtable part of the library doesn’t support currency and you would
> have to handle locking yourself.
>
> *I created a test program to see when it was locking:*
> #include "ink_hash_table.h"
> #include <stdlib.h>
> #include <iostream>
>
> using namespace std;
>
> int main() {
> const char *foo = "hello_world";
> InkHashTable *mine(ink_hash_table_create(InkHashTableKeyType_String));
> ink_hash_table_insert(mine, "foo", (void*)foo);
> char *foo_check = nullptr;
> ink_hash_table_lookup(mine, "foo", (void**)&foo_check);
> cout << foo_check << endl;
> }
>
> Breakpoint 3, 0x00007ffff5ea4da0 in pthread_mutex_lock () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00007ffff65fe927 in ?? () from /lib64/libtcl8.6.so
> #2 0x00007ffff65fed6d in TclpAlloc () from /lib64/libtcl8.6.so
> #3 0x00007ffff65213c8 in Tcl_Alloc () from /lib64/libtcl8.6.so
> #4 0x00007ffff65b6315 in ?? () from /lib64/libtcl8.6.so
> #5 0x00007ffff65b64c7 in ?? () from /lib64/libtcl8.6.so
> #6 0x00007ffff7bafe67 in ink_hash_table_get_entry (ht_ptr=<optimized
> out>, key=<optimized out>, new_value=<optimized out>) at
> ink_hash_table.cc:244
> #7 0x00007ffff7bafeb6 in ink_hash_table_insert (ht_ptr=ht_ptr@entry=0x614010,
> key=key@entry=0x400b3c "foo", value=value@entry=0x400b30) at
> ink_hash_table.cc:293
> #8 0x0000000000400951 in main () at test_ink_hash_table.cc:10
> (gdb) cont
>
> -Bryan
>
>
>
> On Sep 29, 2017, at 1:50 PM, CrazyCow <zh...@gmail.com> wrote:
>
> I read the code of Tcl_HashTable. They say nothing about handling
> concurrency.
>
> The biggest concern about this is, as Alan and Bryan said, what level of
> use will we have for ATS.
> I read docs <https://www.threadingbuildingblocks.org/docs/help/index.htm>
> of TBB. It's offering rich tools of handling threading issues. We can look
> into it more to see if there are other utilities appealing.
> Generally speaking, nice docs, good reputation, and upcoming new releases
> are signs of tbb being a good choice.
>
> 2017-09-29 12:11 GMT-07:00 Bryan Call <bc...@apache.org>:
>
>> This seems like a large dependency to pull in to get a thread safe
>> unordered map. We already have a dependency on Tcl_HashTable
>> (InkHashTable), that handles concurrency, and it used throughout the code
>> base.
>>
>> -Bryan
>>
>>
>>
>> On Sep 28, 2017, at 5:55 PM, CrazyCow <zh...@gmail.com> wrote:
>>
>> Hi, ATS devs,
>>
>> Currently, we have a requirement of concurrent_unordered_map (details can
>> be found https://github.com/apache/trafficserver/pull/2555). And
>> intel::tbb::concurrent_unordered_map is the most mature one we can try
>> out.
>> I understand this dependency is huge. I'd like to hear opinions from you
>> guys, that whether we need to do it or not and if yes, what is the best
>> approach to introduce it.
>>
>>
>> Thanks,
>> Zizhong
>>
>>
>>
>
>
>
Re: [Dependency Proposal] intel::tbb
Posted by Jason Kenny <jk...@oath.com.INVALID>.
interesting to not the junction make will use TBB under the covers...
for example:
https://github.com/preshing/junction/blob/14c0b8f835d26899c22eb7e747ccdffb775c49f2/junction/extra/impl/MapAdapter_TBB.h
On Fri, Sep 29, 2017 at 5:13 PM, Bryan Call <bc...@apache.org> wrote:
> Here are some benchmark numbers I ran across when looking at different
> thread safe hash implementations:
>
>
>
>
> Source: http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/
>
> -Bryan
>
>
>
> On Sep 29, 2017, at 2:42 PM, Bryan Call <bc...@apache.org> wrote:
>
> TCL handles concurrency for memory allocation bits. Looking at it more,
> the hashtable part of the library doesn’t support currency and you would
> have to handle locking yourself.
>
> *I created a test program to see when it was locking:*
> #include "ink_hash_table.h"
> #include <stdlib.h>
> #include <iostream>
>
> using namespace std;
>
> int main() {
> const char *foo = "hello_world";
> InkHashTable *mine(ink_hash_table_create(InkHashTableKeyType_String));
> ink_hash_table_insert(mine, "foo", (void*)foo);
> char *foo_check = nullptr;
> ink_hash_table_lookup(mine, "foo", (void**)&foo_check);
> cout << foo_check << endl;
> }
>
> Breakpoint 3, 0x00007ffff5ea4da0 in pthread_mutex_lock () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00007ffff65fe927 in ?? () from /lib64/libtcl8.6.so
> #2 0x00007ffff65fed6d in TclpAlloc () from /lib64/libtcl8.6.so
> #3 0x00007ffff65213c8 in Tcl_Alloc () from /lib64/libtcl8.6.so
> #4 0x00007ffff65b6315 in ?? () from /lib64/libtcl8.6.so
> #5 0x00007ffff65b64c7 in ?? () from /lib64/libtcl8.6.so
> #6 0x00007ffff7bafe67 in ink_hash_table_get_entry (ht_ptr=<optimized
> out>, key=<optimized out>, new_value=<optimized out>) at
> ink_hash_table.cc:244
> #7 0x00007ffff7bafeb6 in ink_hash_table_insert (ht_ptr=ht_ptr@entry=0x614010,
> key=key@entry=0x400b3c "foo", value=value@entry=0x400b30) at
> ink_hash_table.cc:293
> #8 0x0000000000400951 in main () at test_ink_hash_table.cc:10
> (gdb) cont
>
> -Bryan
>
>
>
> On Sep 29, 2017, at 1:50 PM, CrazyCow <zh...@gmail.com> wrote:
>
> I read the code of Tcl_HashTable. They say nothing about handling
> concurrency.
>
> The biggest concern about this is, as Alan and Bryan said, what level of
> use will we have for ATS.
> I read docs <https://www.threadingbuildingblocks.org/docs/help/index.htm>
> of TBB. It's offering rich tools of handling threading issues. We can look
> into it more to see if there are other utilities appealing.
> Generally speaking, nice docs, good reputation, and upcoming new releases
> are signs of tbb being a good choice.
>
> 2017-09-29 12:11 GMT-07:00 Bryan Call <bc...@apache.org>:
>
>> This seems like a large dependency to pull in to get a thread safe
>> unordered map. We already have a dependency on Tcl_HashTable
>> (InkHashTable), that handles concurrency, and it used throughout the code
>> base.
>>
>> -Bryan
>>
>>
>>
>> On Sep 28, 2017, at 5:55 PM, CrazyCow <zh...@gmail.com> wrote:
>>
>> Hi, ATS devs,
>>
>> Currently, we have a requirement of concurrent_unordered_map (details can
>> be found https://github.com/apache/trafficserver/pull/2555). And
>> intel::tbb::concurrent_unordered_map is the most mature one we can try
>> out.
>> I understand this dependency is huge. I'd like to hear opinions from you
>> guys, that whether we need to do it or not and if yes, what is the best
>> approach to introduce it.
>>
>>
>> Thanks,
>> Zizhong
>>
>>
>>
>
>
>
Re: [Dependency Proposal] intel::tbb
Posted by Bryan Call <bc...@apache.org>.
Here are some benchmark numbers I ran across when looking at different thread safe hash implementations:
Source: http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/ <http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/>
-Bryan
> On Sep 29, 2017, at 2:42 PM, Bryan Call <bc...@apache.org> wrote:
>
> TCL handles concurrency for memory allocation bits. Looking at it more, the hashtable part of the library doesn’t support currency and you would have to handle locking yourself.
>
> I created a test program to see when it was locking:
> #include "ink_hash_table.h"
> #include <stdlib.h>
> #include <iostream>
>
> using namespace std;
>
> int main() {
> const char *foo = "hello_world";
> InkHashTable *mine(ink_hash_table_create(InkHashTableKeyType_String));
> ink_hash_table_insert(mine, "foo", (void*)foo);
> char *foo_check = nullptr;
> ink_hash_table_lookup(mine, "foo", (void**)&foo_check);
> cout << foo_check << endl;
> }
>
> Breakpoint 3, 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> (gdb) bt
> #0 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00007ffff65fe927 in ?? () from /lib64/libtcl8.6.so
> #2 0x00007ffff65fed6d in TclpAlloc () from /lib64/libtcl8.6.so
> #3 0x00007ffff65213c8 in Tcl_Alloc () from /lib64/libtcl8.6.so
> #4 0x00007ffff65b6315 in ?? () from /lib64/libtcl8.6.so
> #5 0x00007ffff65b64c7 in ?? () from /lib64/libtcl8.6.so
> #6 0x00007ffff7bafe67 in ink_hash_table_get_entry (ht_ptr=<optimized out>, key=<optimized out>, new_value=<optimized out>) at ink_hash_table.cc:244 <http://ink_hash_table.cc:244/>
> #7 0x00007ffff7bafeb6 in ink_hash_table_insert (ht_ptr=ht_ptr@entry=0x614010, key=key@entry=0x400b3c "foo", value=value@entry=0x400b30) at ink_hash_table.cc:293 <http://ink_hash_table.cc:293/>
> #8 0x0000000000400951 in main () at test_ink_hash_table.cc:10 <http://test_ink_hash_table.cc:10/>
> (gdb) cont
>
> -Bryan
>
>
>
>> On Sep 29, 2017, at 1:50 PM, CrazyCow <zhangzizhong0828@gmail.com <ma...@gmail.com>> wrote:
>>
>> I read the code of Tcl_HashTable. They say nothing about handling concurrency.
>>
>> The biggest concern about this is, as Alan and Bryan said, what level of use will we have for ATS.
>> I read docs <https://www.threadingbuildingblocks.org/docs/help/index.htm> of TBB. It's offering rich tools of handling threading issues. We can look into it more to see if there are other utilities appealing.
>> Generally speaking, nice docs, good reputation, and upcoming new releases are signs of tbb being a good choice.
>>
>> 2017-09-29 12:11 GMT-07:00 Bryan Call <bcall@apache.org <ma...@apache.org>>:
>> This seems like a large dependency to pull in to get a thread safe unordered map. We already have a dependency on Tcl_HashTable (InkHashTable), that handles concurrency, and it used throughout the code base.
>>
>> -Bryan
>>
>>
>>
>>> On Sep 28, 2017, at 5:55 PM, CrazyCow <zhangzizhong0828@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Hi, ATS devs,
>>>
>>> Currently, we have a requirement of concurrent_unordered_map (details can be found https://github.com/apache/trafficserver/pull/2555 <https://github.com/apache/trafficserver/pull/2555>). And intel::tbb::concurrent_unordered_map is the most mature one we can try out.
>>> I understand this dependency is huge. I'd like to hear opinions from you guys, that whether we need to do it or not and if yes, what is the best approach to introduce it.
>>>
>>>
>>> Thanks,
>>> Zizhong
>>
>>
>
Re: [Dependency Proposal] intel::tbb
Posted by Bryan Call <bc...@apache.org>.
TCL handles concurrency for memory allocation bits. Looking at it more, the hashtable part of the library doesn’t support currency and you would have to handle locking yourself.
I created a test program to see when it was locking:
#include "ink_hash_table.h"
#include <stdlib.h>
#include <iostream>
using namespace std;
int main() {
const char *foo = "hello_world";
InkHashTable *mine(ink_hash_table_create(InkHashTableKeyType_String));
ink_hash_table_insert(mine, "foo", (void*)foo);
char *foo_check = nullptr;
ink_hash_table_lookup(mine, "foo", (void**)&foo_check);
cout << foo_check << endl;
}
Breakpoint 3, 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1 0x00007ffff65fe927 in ?? () from /lib64/libtcl8.6.so
#2 0x00007ffff65fed6d in TclpAlloc () from /lib64/libtcl8.6.so
#3 0x00007ffff65213c8 in Tcl_Alloc () from /lib64/libtcl8.6.so
#4 0x00007ffff65b6315 in ?? () from /lib64/libtcl8.6.so
#5 0x00007ffff65b64c7 in ?? () from /lib64/libtcl8.6.so
#6 0x00007ffff7bafe67 in ink_hash_table_get_entry (ht_ptr=<optimized out>, key=<optimized out>, new_value=<optimized out>) at ink_hash_table.cc:244
#7 0x00007ffff7bafeb6 in ink_hash_table_insert (ht_ptr=ht_ptr@entry=0x614010, key=key@entry=0x400b3c "foo", value=value@entry=0x400b30) at ink_hash_table.cc:293
#8 0x0000000000400951 in main () at test_ink_hash_table.cc:10
(gdb) cont
-Bryan
> On Sep 29, 2017, at 1:50 PM, CrazyCow <zh...@gmail.com> wrote:
>
> I read the code of Tcl_HashTable. They say nothing about handling concurrency.
>
> The biggest concern about this is, as Alan and Bryan said, what level of use will we have for ATS.
> I read docs <https://www.threadingbuildingblocks.org/docs/help/index.htm> of TBB. It's offering rich tools of handling threading issues. We can look into it more to see if there are other utilities appealing.
> Generally speaking, nice docs, good reputation, and upcoming new releases are signs of tbb being a good choice.
>
> 2017-09-29 12:11 GMT-07:00 Bryan Call <bcall@apache.org <ma...@apache.org>>:
> This seems like a large dependency to pull in to get a thread safe unordered map. We already have a dependency on Tcl_HashTable (InkHashTable), that handles concurrency, and it used throughout the code base.
>
> -Bryan
>
>
>
>> On Sep 28, 2017, at 5:55 PM, CrazyCow <zhangzizhong0828@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi, ATS devs,
>>
>> Currently, we have a requirement of concurrent_unordered_map (details can be found https://github.com/apache/trafficserver/pull/2555 <https://github.com/apache/trafficserver/pull/2555>). And intel::tbb::concurrent_unordered_map is the most mature one we can try out.
>> I understand this dependency is huge. I'd like to hear opinions from you guys, that whether we need to do it or not and if yes, what is the best approach to introduce it.
>>
>>
>> Thanks,
>> Zizhong
>
>
Re: [Dependency Proposal] intel::tbb
Posted by CrazyCow <zh...@gmail.com>.
I read the code of Tcl_HashTable. They say nothing about handling
concurrency.
The biggest concern about this is, as Alan and Bryan said, what level of
use will we have for ATS.
I read docs <https://www.threadingbuildingblocks.org/docs/help/index.htm>
of TBB. It's offering rich tools of handling threading issues. We can look
into it more to see if there are other utilities appealing.
Generally speaking, nice docs, good reputation, and upcoming new releases
are signs of tbb being a good choice.
2017-09-29 12:11 GMT-07:00 Bryan Call <bc...@apache.org>:
> This seems like a large dependency to pull in to get a thread safe
> unordered map. We already have a dependency on Tcl_HashTable
> (InkHashTable), that handles concurrency, and it used throughout the code
> base.
>
> -Bryan
>
>
>
> On Sep 28, 2017, at 5:55 PM, CrazyCow <zh...@gmail.com> wrote:
>
> Hi, ATS devs,
>
> Currently, we have a requirement of concurrent_unordered_map (details can
> be found https://github.com/apache/trafficserver/pull/2555). And
> intel::tbb::concurrent_unordered_map is the most mature one we can try
> out.
> I understand this dependency is huge. I'd like to hear opinions from you
> guys, that whether we need to do it or not and if yes, what is the best
> approach to introduce it.
>
>
> Thanks,
> Zizhong
>
>
>
Re: [Dependency Proposal] intel::tbb
Posted by Bryan Call <bc...@apache.org>.
This seems like a large dependency to pull in to get a thread safe unordered map. We already have a dependency on Tcl_HashTable (InkHashTable), that handles concurrency, and it used throughout the code base.
-Bryan
> On Sep 28, 2017, at 5:55 PM, CrazyCow <zh...@gmail.com> wrote:
>
> Hi, ATS devs,
>
> Currently, we have a requirement of concurrent_unordered_map (details can be found https://github.com/apache/trafficserver/pull/2555 <https://github.com/apache/trafficserver/pull/2555>). And intel::tbb::concurrent_unordered_map is the most mature one we can try out.
> I understand this dependency is huge. I'd like to hear opinions from you guys, that whether we need to do it or not and if yes, what is the best approach to introduce it.
>
>
> Thanks,
> Zizhong