Add static storage for bounded # of dtls keys/vals
authorKevin Klues <klueska@cs.berkeley.edu>
Tue, 25 Aug 2015 01:18:27 +0000 (18:18 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 2 Sep 2015 17:50:05 +0000 (13:50 -0400)
commit1d25aa051c00d44ecc4a1f05986f88bb4b7f390f
tree37bfb1e7ec714b30fd464c31cc29b8738f066b08
parent5348fbdaf137ebbd8cf2601d51e0bcfc62d9c037
Add static storage for bounded # of dtls keys/vals

Storage for up to NUM_STATIC_KEYS is now statically allocated for dtls
keys. Likewise, per-thread storage for the values associated with these
keys is allocated as part of a thread's static TLS data (in an array
called 'early_values').  By statically allocating this data, we avoid
having to dynamically allocate memory for a small number of DTLS keys
and their associated values.  Moreover, we have a faster lookup time for
these key/value pairs because we know exactly where to look for their
values by indexing into an array instead of searching through a linked
list.

Realistically, dtls keys will likely go unused in most apps today, in
favor of compiler supported TLS via __thread. For this reason, we chose
to only optimize for a small number of keys since it's likely that we
won't every go beyond this value in a real application.  If we do, we
can revisit this implementation and do something more sophisticated
along the lines of what glibc does in its pthread_key_create() and
pthread_get/setspecific() calls (i.e. use a 2-level array structure with
a finite bound on the number of keys).  For now, what we have is
sufficient for the apps we've encountered.

Overall, it may seem weird to store the dtls early_values array inside
of a __thread variable (since the whole point of dtls is to enable
dynamically allocated TLS when compiler supported TLS is unavailable),
but we mostly only provide dtls for backwards compatibility and plan to
always enable compiler supported TLS for apps that require TLS of any
sort.
user/parlib/dtls.c