Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Jul 1999 15:37:16 +1000
From:      "Andrew Reilly" <a.reilly@lake.com.au>
To:        Mike Smith <mike@smith.net.au>
Cc:        Mike Haertel <mike@ducky.net>, Matthew Dillon <dillon@apollo.backplane.com>, Luoqi Chen <luoqi@watermarkgroup.com>, dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG
Subject:   Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
Message-ID:  <19990713153716.A94421@gurney.reilly.home>
In-Reply-To: <199907130209.TAA03301@dingo.cdrom.com>; from Mike Smith on Mon, Jul 12, 1999 at 07:09:58PM -0700
References:  <199907121741.KAA17837@ducky.net> <199907130209.TAA03301@dingo.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote:
> > Although function calls are more expensive than inline code,
> > they aren't necessarily a lot more so, and function calls to
> > non-locked RMW operations are certainly much cheaper than
> > inline locked RMW operations.
> 
> This is a fairly key statement in context, and an opinion here would 
> count for a lot; are function calls likely to become more or less 
> expensive in time?

Others have answered this question, but I thought I'd point out
that there is another alternative that is likely to be faster
than indirect function calls on some architectures: inline
branched code.  So you still have a global variable selecting
locked/non-locked, but it's a boolean, rather than a pointer.
Your atomic macros are then { if (atomic_lock) asm("lock;foo");
else asm ("foo"); }

You might be interested in the paper:

"Efficient Dynamic Dispatch without Virtual Function Tables. The
SmallEiffel Compiler." Olivier ZENDRA, Dominique COLNET, Suzanne
COLLIN. 12th Annual ACM SIGPLAN Conference on Object-Oriented
Programming, Systems, Languages, and Applications (OOPSLA'97),
Volume 32, Issue 10 - Atlanta, GA, USA, October 1997, pages 125-141.

http://SmallEiffel.loria.fr/papers/papers.html#OOPSLA97

as a justification for that approach.

-- 
Andrew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990713153716.A94421>