[vmkit-commits] FatLock assertion failure?

[Will Dietz]

On Tue, Nov 29, 2011 at 10:01 AM, Nicolas Geoffray
<nicolas.geoffray at gmail.com> wrote:
> Hi Will,
>
> On Tue, Nov 29, 2011 at 3:59 PM, Will Dietz <wdietz2 at illinois.edu> wrote:
>>
>> Hi,
>>
>> On both runtimes, I'm seeing the following assertion occur
>> periodically (unpredictably, same code sometimes tickles it other
>> times not)
>>
>> j3: /home/will/vmkit-svn/lib/vmkit/CommonThread/ObjectLocks.cpp:305:
>> bool vmkit::FatLock::acquire(gc *): Assertion `obj->header &
>> ThinLock::FatMask' failed.
>
> That's because you have too many cores :).... That's a lame answer. The real
> answer is that there is a bug somewhere in the locking implementation. I
> also experience in on my desktop machine (8 cores), but never on my laptop
> (2 cores).
> Nicolas
>

Thanks!

Inspired by your response, I looked into this a bit and seem to have a
bit more on the issue:

The problem occurs when we try to deflate a fat lock back to a thin
lock--there's a race on the object headers that makes the guard (that
wants to be "does anyone have a pointer to this lock anywhere") unsafe
(ObjectLocks.cpp:278-279).  Indeed (from my limited understanding of
the literature, gulp) this seems to be a tricky problem in general and
not just a bug of this implementation.

Given this, and that we probably want locks to work on SMP machines
(well, I sure do! :D), it seems we have at least two solutions:

* Implement a more complicated locking solution ("tasuki" locks?).
* Disallow deflating of fat locks altogether.  I've done this locally
to great success--a lot of mysterious crashes/assertion failures are
now gone.  Downside is potential performance hit in terms of locking
overhead and lock resource utilization.

I'm inclined to suggest we just go with the latter, and put the former
on the TODO list... but of course it's up to you, and I'm curious what
your thoughts on all this are :).

Thanks!

~Will