On Saturday 16 August 2014 at 10:09:44, Edward Shishkin wrote:
>
> On 08/16/2014 02:44 AM, Ivan Shapovalov wrote:
> > On Monday 11 August 2014 at 13:39:12, Ivan Shapovalov wrote:
> >> [...]
> >>>> I've meant "grabbing all space and then allocating all space" -- so there won't
> >>>> be multiple grabs or multiple atoms.
> >>>>
> >>>> Then all processes grabbing space with BA_CAN_COMMIT will wait for the discard
> >>>> atom to commit.
> >>>
> >>> It seems such waiting will screw up the system. No?
> >> I was afraid of such situations, but how would that happen? The discard atom's
> >> commit will always be able to proceed as it doesn't grab space at all.
> >>
> >>>> (Actually, there is a small race window between grabbing space
> >>>> and creating an atom...)
> >>>
> >>> Which one?
> >> BA_CAN_COMMIT machinery does wait only for atoms, not for contexts. If
> >> process X happens to grab space between us grabbing space and creating an atom,
> >> it will get -ENOSPC even with BA_CAN_COMMIT.
>
>
> I still don't see any "races" here. How atom creation is related to grabbing
> space? Are we talking about races in the existing code? f so, please show
> the racing paths..
Well, this is not a race per se - it does not involve locking. But it is
a race-like behavior.
taskA taskB
--------------------------------------------------------------------------
grab very much space
grab some space with BA_CAN_COMMIT
create an atom using the grabbed space
In this case, the taskB's grab will fail though it could wait for taskA's
not yet created atom.
--
Ivan Shapovalov / intelfx /Attachment:
signature.asc
Description: This is a digitally signed message part.
