Re: CAS (lws_compare_and_swap32)
On Mon, 29 Mar 2010, Carlos O'Donell wrote:
> >> prev = *addr;
> >> if ( prev == old )
> >> *addr = new;
> >> return prev;
> >> */
> >> [...]
> >> cas_action:
> >> [...]
> >> /* The load and store could fail */
> >> 1: ldw 0(%sr3,%r26), %r28
> >> sub,<> %r28, %r25, %r0
> >> 2: stw %r24, 0(%sr3,%r26)
> >> ----------------
> >>
> >> Suppose that <addr> points to copy-on-write memory. At the label 2,
> >> storing data to <addr> will invoke memory trap and it will go to
> >> do_page_fault() to get new memory. In this scenario, is there a
> >> possibility for the process to be scheduled off?
> > At the time I wrote it I tried to verify that the process calling the
> > CAS could never sleep, since this would make it non-atomic.
> >
> > There are checks in entry.S to prevent return code-paths from
> > scheduling or delivering signals if the process was executing on the
> > gateway page.
> >
> > If we are certain that the above could happen, then a possible solution is:
> > * Enable locks for SMP and UP.
> > * If lock is taken for your addresss, return to userspace with EAGAIN.
> > * Userspace yields on EAGAIN and then tries again (we can't use
> > FUTEX_WAIT/FUTEX_WAKE on a global process unique variable because LWS
> > CAS is expected to work on shmem).
I think the solution may be to proceed the CAS sequence with a probe,w
instruction. This will trigger a non-access TLB miss fault/non-access
data page fault if its going to happen. There is a FIXME for case 17
in handle_interruption about this.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Reply to: