Messages in this thread | | | Date | Wed, 22 Feb 2012 08:32:51 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 2012-02-21 at 15:20 -0500, Jason Baron wrote: > > > I'm not really too hung up on the naming, but I did think > > that very_[un]likely were an interesting possibility. > > The problem comes from what Peter said. They are too similar > to "likely()" and "unlikely()", and can become confusing.
See my other mail.
> Maybe "static_likely()" and "static_unlikely()" as the word > "static" can imply something strange about these. Or perhaps a > "const_likely()"? > > Maybe "dynamic_branch_true()" and "dynamic_branch_false()". This may be > the most descriptive.
too long.
'static branch' or 'static condition' is not a bad concept, if people don't find the similarity to 'static' too confusing ;-).
But it is fundamentally mixing execution and *data type* and it is not conveying the build time bias properly.
So the best high level naming would be something like:
struct static_condition static_flag = STATIC_COND_FALSE;
if (very_unlikely(&static_flag)) { ... }
...
static_cond_inc(&static_flag); ... static_cond_dec(&static_flag);
See how *both* the build time bias and the cost of a state transition is properly conveyed?
I suggested something like this to Jason in the off-list discusion and it's not fully implemented yet. Let me whip up a test branch [pun and potential confusion unintended] that shows it.
Thanks,
Ingo
| |