comp.lang.c++

"Lew" wrote in message
news:TdidnYSbe-nVnZzVnZ2dnUVZ_jqdnZ2d@comcast.com...
> "Lew" wrote
>>> However, Roedy did not mention a "global pointer". You introduced that
>>> into the conversation, and have yet to explain what you mean by that.
>
> Chris Thomasson wrote:
>> I mean atomically incrementing a global pointer off a common base of
>> memory. This is basic memory allocator implementation 101. You know this.
>> Perhaps Roedy was talking about a distributed model. What say you?
>
> I'll repeat what I said, but in different words in hope that I am clearer.
>
> What Roedy meant is that Java allocators simply increment the pointer to
> available memory by the size of the allocation. Details of *which* memory
> pointer, and any synchronization needed if any, are left to the JVM. This
> process is in-built to the semantics of the 'new' operator. One does not
> explicitly manage any of that. I could not tell you if the operation
> involves a global pointer or not without checking the specifics of a
> particular JVM implementation, of which there are several from different
> vendors.
>
>> Java can use both, and all methods in between. You don't necessarily want
>> to send atomic mutations to a common location. Perhaps Roedy meant N
>> counts off the bases of multiple memory pools. I don't know. I was
>> speculating. I hope I was wrong. I thought he meant count off a single
>> location. That's not going to scale very well... You can break big
>
> It scales just fine. The American IRS accepts millions of
> electronically-filed tax returns in just a few days through such a system.

My first point, wrt sending atomic mutations to a COMMON location:

Applying "frequent" atomic mutations to a _single_ location does not scale
well at all. This fairly common mistake ends up generates high amounts of
unneeded cache coherency traffic. Your going to ping-pong and simply
saturate the FSB. Post over to comp.programming.threads if you want to know
why this does not scale fine at all. Try and do that on a NUMA system... Not
going to work. Well, it will work, its just going to give very bad
performance.

I know some things about distributed programming... Why would you want
anything that calls new to atomically increment a global singular pointer?
What if then threads which are running on ten separate CPUS to all contend
for a single location in memory? That is not good at all. I have designed
distributed locking schemes, and can tell you that contention on a
per-thread/cpu mutex is MUCH better than contention on a single mutex. This
is directly analogous to multiple CPUS firing atomic updates at a SINGLE
location. Again, post over on c.p.t so we can give you much more detailed
information.

Java can use many different techniques. I don't see why it would ever need
to focus contention on a common location. IMVHO, Java benefits from
distributed memory allocator algorithms.

[...]


I am still thinking about the rest of your post, I just don't have time
right now to make a full response.