Re: CAS (lws_compare_and_swap32)
On Mon, Mar 29, 2010 at 9:54 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> 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.
Then what though? One process has to write to the page to initiate the
COW. How else are you going to initiate the COW? Once in userspace you
are only allowed to write to the CAS value (one word on a page), and
you *can't* because that would violate the CAS semantics and atomicity
requirements.
The "first" process must take the lock, has to write the result to the
page, has to initiate the COW, has to sleep with the lock held, and
the rest have to spin in userpace waiting for it to complete.
AFAICT the rest of the processes are not be able to stop the "first"
process from finishing the COW, so we make forward progress after the
COW is done and the "first" process resumes and unlocks the LWS CAS
lock (for that address range).
Cheers,
Carlos.
Reply to: