river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: datastructure classes
Date Tue, 21 Dec 2010 09:08:13 GMT
An old geek joke, related to the mad trademarking of just about anything....

On 21 December 2010 00:28, MICHAEL MCGRADY <mmcgrady@topiatechnology.com>wrote:

> Dan, what is "(TM)"?
>
> On Dec 20, 2010, at 1:13 PM, Dan Creswell wrote:
>
> > Blitz too has optional FIFO-ness via configuration though it's absolutely
> a
> > performance killer for any decent concurrent load by virtue of the usual
> > suspects such as lock contention and the high chance of scanning entry's
> > that have just been taken by a thread just ahead in the queue.
> >
> > To be honest though, unless FIFO is spec'd officially as an option or a
> > default, having developers rely on magic such as FIFO by default is "very
> > bad" (TM).
> >
> > On 20 December 2010 20:30, Patricia Shanahan <pats@acm.org> wrote:
> >
> >> Tom Hobbs wrote:
> >>
> >>> I know of at least one company which uses Outrigger specifically
> >>> because of it's fortuitous FIFO behaviour.  I'm trying to encourage
> >>> them to move from the Jini 2.1 code to the River release and losing
> >>> the FIFO-ness might be an issue for them.
> >>>
> >>> And yes I know, the spec doesn't specify FIFO, like I said, they
> >>> needed a FIFO space, and Outrigger "just happened" to behave like
> >>> that.
> >>>
> >>
> >> That confirms my suspicion that FIFO-ness is a useful property. I note
> that
> >> Gigaspaces has optional support for FIFO.
> >>
> >> My quick changes to try to fix the current bug will preserve it. If the
> >> long term design loses it for flat-out performance, we should make it
> >> available on a configuration basis.
> >>
> >> Patricia
> >>
> >>
> >>
>
> Michael McGrady
> Chief Architect
> Topia Technology, Inc.
> Cel 1.253.720.3365
> Work 1.253.572.9712 extension 2037
> mmcgrady@topiatechnology.com
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message