can you give a short description of this allocator?
-dean
On Sat, 21 Apr 2001, Cliff Woolley wrote:
> On Sat, 21 Apr 2001, Greg Ames wrote:
>
> > are you thinking about an atomic push/pop block allocator? I'll be
> > happy to help out if so, especially with the machine instruction level
> > stuff.
>
> Yes, I am, and I definitely *will* need help from various people getting
> the appropriate machine language magic for their platforms working. I've
> already done the generic fallback locking implementation of the stack;
> that was simple. And I have what you and Jeff gave me for S390. But...
>
> > yeah, but that stuff can go away. compare-and-exchange (or compare &
> > swap, or load & reserve, or...) is our friend in multithreaded systems,
> > especially on multiprocessors. The piece I haven't figured out is how
> > to set up CPU architecture dependent directories, or macros, or
> > whatever, in APR. <sigh>
>
> THAT's the problem. No other piece of APR is *architecture* dependent.
> There's an "arch" include directory, but it's really a misnamed "os"
> directory. I've got a scheme implemented that gives us an APR_ARCH_IS_foo
> macro, but it's a hack. It disobeys the typical APR rule of "all macros
> are always defined and have a value of 0 or 1" and is just defined or not.
> I've also been afraid that some of the possible ways to implement these
> machine-language tricks will also be *compiler* dependent, not just
> architecture dependent. If so, then that makes this that much harder.
> For example, I've taken your jstack.h and pulled out the __cds() "calls"
> and wrapped a macro around them so that different architectures can insert
> their equivalent instruction. But are "__cds()" and "cds_t" available on
> all S390 platforms? I'm guessing no. Ugh. If anybody has a clean way to
> do this, I'm all ears.
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> [EMAIL PROTECTED]
> Charlottesville, VA
>
>
>
