|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Alan Stern <stern-AT-rowland.harvard.edu> |
|| ||Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33) |
|| ||Tue, 8 Dec 2009 08:42:35 -0800 (PST)|
|| ||"Rafael J. Wysocki" <rjw-AT-sisk.pl>, Zhang Rui <rui.zhang-AT-intel.com>,
ACPI Devel Maling List <linux-acpi-AT-vger.kernel.org>,
pm list <linux-pm-AT-lists.linux-foundation.org>|
|| ||Article, Thread
On Tue, 8 Dec 2009, Alan Stern wrote:
> The semantics needed for this kind of lock aren't really the same as
> for an rwsem (although obviously an rwsem will do the job). Basically
> it needs to have the capability for multiple users to lock it (no
> blocking when acquiring a lock) and the capability for a user to wait
> until it is totally unlocked. It could be implemented trivially using
> an atomic_t counter and a waitqueue head.
> Is this a standard sort of lock?
Yes it is.
It's called a rwlock. The counter is for readers, the exclusion is for
And the thing is, you actually do want the rwlock semantics, because on
the resume side you want the parent to lock it for writing first (so that
the children can wait for the parent to have completed its resume.
So we actually _want_ the full rwlock semantics.
See the code I posted earlier. Here condensed into one email:
// Wait for parent to finish resume
// .. before resuming outselves
// Now we're all done
/* caller: */
// This won't block, because we resume parents before children,
// and the children will take the read lock.
// Do the blocking part asynchronously
// Start our suspend. This will block if we have any
// children that are still busy suspending (they will
// have done a down_read() in their suspend).
// This lets our parent continue
/* caller: */
// This won't block, because we suspend nodes before parents
// Do the part that may block asynchronously
It really should be that simple. Nothing more, nothing less. And with the
above, finishing the suspend (or resume) from interrupts is fine, and you
don't have any new lock that has undefined memory ordering issues etc.
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)