> Date: Sat, 21 Dec 2013 02:29:49 -0500
> From: Ted Unangst <t...@tedunangst.com>
>
> On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
> > This patch fixes problems in KDE4, that relies on sharing (process-shared)
> > semaphores via mmap(). This feature is used in the wild, so if we claim
> > that we support process-shared semaphores, we have to implement it, too.
>
> Haven't forgotten about this.
>
> > Dirty games with "lock" member required to avoid exposing extra structure
> > (struct _spinlock) in public header. On the bright side, this diff removes
> > more stuff than it adds, so it have to be a good diff. :)
>
> This is really the troubling part for me. In particular, our spinlock
> implementation isn't all that great. I was poking at it earlier this
> year, but didn't make any progress except to convince myself more work
> needs to be done. Exposing spinlock internals makes experimentation in
> this area more difficult.
>
> I realized my previous replies had only vague promises of pain and
> misery resulting from changing sem_t :), but I've been thinking about
> it a bit more and wanted to make clear that there's a concrete reason
> behind my concern. Unfortunately, there's no timeframe for when I
> expect this to happen, other than I consider spinlock/mutex
> performance a serious issue.
>
> So yes, I'm stalling/slacking, but I hope you'll find the patience to
> wait it out. And if not, let's talk.
It's worth looking at what Linux and Solaris have done here. Linux
only exposes a semi-opaque struct to userland:
typedef union
{
char __size[__SIZEOF_SEM_T];
long int __align;
} sem_t;
It's actually a union, such that you can add a member that forces
alignment, but still specify the size easily in bytes. Might be
better to use 'long long' as the alignment type here though.
If you look at Solaris, you'll realize that they realized too late
that they should have done the same. There only parts of the struct
are opaque.
As Ted pointed out, the size of the struct (or union) becomes part of
the ABI. So we should probably reserve a bit more space than we
actually need for the implementation. That way, we'll leave some room
for experimentation. Wasting a bit more memory shouldn't be a big
issue as typical code that uses semaphores won't be constructing
thousands of these. And rounding up to the nearest power of two
should be pretty much free.
This will cause some ugliness in the actual implementation as we'll
have to cast this semi-opaque struct to the real type there. And we
probably should add a compile-time assert in there to make sure the
real-type isn't bugger than the type we expose to userland.
