On 01/18/15 12:56, Uwe Kleine-König wrote:
Hello,
On Sun, Jan 18, 2015 at 12:46:51PM +0100, Arend van Spriel wrote:
On 01/18/15 12:17, Uwe Kleine-König wrote:
Hello Wolfram,
On Sun, Jan 18, 2015 at 12:06:58PM +0100, Wolfram Sang wrote:
On Sun, Jan 18, 2015 at 10:47:41AM +0100, Uwe Kleine-König wrote:
On Sun, Jan 18, 2015 at 10:14:04AM +0100, Arend van Spriel wrote:
On 01/17/15 00:42, Ray Jui wrote:
+ complete_all(&iproc_i2c->done);
Looking over this code it seems to me there is always a single
process waiting for iproc_i2c->done to complete. So using complete()
here would suffice.
Yeah, there is always only a single thread waiting. That means both
complete and complete_all are suitable. AFAIK there is no reason to pick
one over the other in this case.
Clarity?
And which do you consider more clear? complete_all might result in the
question: "Is there>1 waiter?" and complete might yield to "What about
the other waiters?". If you already know there is only one, both are on
par on clarity. Might only be me?! I don't care much.
Maybe it is me, but it is not about questions but it is about
implicit statements that the code makes (or reader derives from it).
When using complete_all you indicate to the reader "there can be
more than one waiter". When using complete it indicates "there is
only one waiter". If those statements are not true that is a code
No, complete works just fine in the presence of>1 waiter. It just wakes
a single waiter and all others continue to wait.
Yes. Agree.
That is, for single-waiter situations there is no semantic difference
between complete and complete_all. But there is a difference for
multi-waiter queues.
Indeed.
I think this is just a matter of your POV in the single-waiter
situation: complete might be intuitive because you just completed a
single task and complete_all might be intuitive because it signals
"I'm completely done, there is noone waiting for me any more.".
Ok. Let's leave it to the author's intuition or to say it differently
"sorry for the noise" ;-)
Regards,
Arend
Best regards
Uwe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
