Re: rwlock(9) and mutex(9) definitions
- Reply: Gleb Smirnoff : "Re: rwlock(9) and mutex(9) definitions"
- In reply to: Konstantin Belousov : "Re: rwlock(9) and mutex(9) definitions"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 27 Oct 2021 02:06:52 UTC
On Wed, Oct 27, 2021 at 05:03:56AM +0300, Konstantin Belousov wrote:
> On Tue, Oct 26, 2021 at 06:52:21PM -0700, Gleb Smirnoff wrote:
> > Hi,
> >
> > [To: list constructed with help of git blame]
> >
> > despite manual pages describe locking functions as voids in
> > reality some of them (not all) are preprocessor defines wrapped
> > in "do {} while (0)".
> >
> > Such wraps don't really behave as a true void. For example you
> > can not tail call them:
> >
> > void
> > smartass_lock(lock, clue)
> > {
> > if (clue)
> > return (rw_rlock(lock));
> > else
> > return (rw_wlock(lock));
> > }
> >
> > This will fail on rw_wlock, but not on rw_rlock. However, if you
> > have WITNESS it will compile correctly :)
> >
> > So, we need either make these function "static inline void" in
> > mtx.h and rwlock.h, or wrap them in __extension__ ({ }). Btw, the
> > latter is already done for mtx_trylock_spin() by kib in 90b581f2cc327.
> > Of course for try-lock functions inability of tail call is a bigger
> > issue then for voids. However, voids should be fixed as well, I believe.
> >
> > Your call? "static inline" or "__extension__ ({ })"?
>
> Usually defines are easier. For static inline functions, compiler parses
> and validates the definition regardless of its use. So for instance if
> the header is included into userspace compilation consumers, static inlines
> break.
>
> If not that, providing real parseable definitions are better on all other
> counters.
That said, you seems to use wrong syntax for your example. Might be, it
is enough to fix that, and not change the definition?
void
something(bool clue)
{
if (clue) {
rw_rlock(lock);
else
rw_wlock(lock);
}
Both rw_rlock and rw_wlock are in tail context. You cannot _return_ void.