Re: pthread_key_{create,delete} pthread_{g,s}etspecific on NetBSD

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 3,  4:00pm, campbell+netbsd-tech-userlevel%mumble.net@localhost (Taylor 
R Campbell) wrote:
-- Subject: Re: pthread_key_{create,delete} pthread_{g,s}etspecific on NetBSD

| 
|        http://www.netbsd.org/~christos/pthread_key.diff
| 
|    that changes this. Please comment.
| 
| When pulled up to netbsd-6, this patch caused PR 47271.  Quick summary
| for those who weren't following it: the patch ~doubles sizeof(struct
| __pthread_st), which, on i386 and amd64 and probably elsewhere, made
| it span across two pages instead of just one and thereby broke an
| assumption made by netbsd-6's libpthread.  Lifting the assumption is
| easy, but I'm not sure it's the right thing to do about this.
| 
| The reason sizeof(struct __pthread_st) doubled is that we have a fixed
| number, 256, of thread-specific data keys, and each pthread has a
| preallocated fixed-size array of them.  Formerly each key required one
| pointer in each thread; christos's patch adds two more.
| 
| This strikes me as suboptimal and worthy of discussion, although I
| don't have any specific performance problems to cite at the moment.
| Opinions?


Copying the info I posted in the PR so that it is all in one place:

The size increase is not really necessary if you are willing to
pay the cost of going through the all_thread list when you remove
a key (and hold a different lock). Having said that, even in the
case of 1000 threads, this just amounts to 6M of memory on a 64
bit host, instread of ~2M, since I've added 2 pointers to the array
of 256 keys; you need at least one more to hold the data.

christos