[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [Asterisk-Dev] ASTOBJ update
From: "Kevin P. Fleming" <kpfleming () starnetworks ! us>
Date: 2004-12-28 15:09:21
Message-ID: 41D17721.3020906 () starnetworks ! us
[Download RAW message or body]
Matthew Boehm wrote:
> #define ASTOBJ_WRLOCK(object) ast_mutex_lock(&(object)->_lock)
>
> Why is using this macro better than just calling the function? What kind of
> performance gain is seen? Where is it seen?
In addition to what I already responded with, there's another benefit:
opacity. It's better to hide the implementation details from the ASTOBJ
users so that people don't try to intentionally do things in a different
(possibly incompatible and/or broken) way. Obviously everyone can see
the source and figure out what is going on, but if a future version of
ASTOBJ should use a very different locking model then we don't have to
worry about changing callers, especially since that change might be much
more difficult than a search-and-replace.
For example, there are "lockless" list reading algorithms out there
(IBM's RCU is one). If we should decide to integrate one of those at
some point, then doing a "search-and-replace" on ast_mutex_lock for
everyone using ASTOBJ variables would be a very time consuming and
error-prone task. Redefining ASTOBJ_RDLOCK to a no-op takes about 5
seconds :-)
This discussion has brought up something I hadn't considered yesterday
though... we need another set of macros for locking, to be used when the
object is being locked in its "list container" role, as opposed to its
"object" role. That way we can split them apart if needed in the future.
Watch for a new patch :-)
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic