[cfe-commits] patch: libcxxabi cxa_*_virtual and cxa_guard_* methods

[John McCall]

On May 22, 2011, at 1:45 PM, Nick Lewycky wrote:

> On 22 May 2011 12:23, Howard Hinnant <hhinnant at apple.com> wrote:
> On May 20, 2011, at 2:11 AM, Nick Lewycky wrote:
> 
> > I've started dipping my toes in the libcxxabi project by implementing a few simple methods. Patch attached, please review!
> >
> > This isn't heavily tested, I'm mostly just trying to make sure I have the style down. Please let me know if we should be using different file names (hard to follow a pattern where there isn't one), of if the private methods in cxa_guard actually belong in an anonymous namespace, etc.
> >
> > Nick
> >
> > <libcxxabi-virtual-and-guard.patch>
> 
> I disagree with John that your implementation doesn't support the recursive calls for *different* static objects.  I believe it does.
> 
> Thanks. I was just about to write up an email to the same effect. It does support recursive calls for different static objects because the lock it uses is the second byte of the guard variable, not a global (or per-thread) lock.

Yeah, sorry about that.

> Back when I thought that we needed to support self-recursive initialization, I came up with a way to do this. The fundamental problem with pthread_self() is that it returns an 8-byte opaque object (ie., they aren't guaranteed to be dense), and C++11's thread library is worse. (Linux supports "gettid()" which returns a 4-byte ID which would fit neatly in the guard variable, but let's leave that aside for the moment.) We can construct our own thread ID by creating a thread_local variable, and we can make it use only 7 bytes by giving it 256 byte alignment. The recursion depth counter would then be kept on the initialization byte (supporting 254 levels of recursion depth with values 0 and 1 reserved for an unlocked guard variable).

This won't work;  the initialization byte has to stay zero until initialization is complete.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110522/978f50bf/attachment.html>