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@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
