Thanks for the replies.
I will give you an example of what (I believe, trying to find out if I
am wrong) happens with MINA. MINA has an IoFilterChain where you can
plug in a ThreadPool ExecutorFilter.
I am basing this understanding on my interpretation of the Java Language
specification so when I say thread memory and shared memory I think I am
talking about RAM allocated for different purposes.
Am I correct in thinking that on a request data is read from a socket to
the IO processor thread memory, then copied to shared memory, then again
to ExecutorFilter thread before being operated on?
If this is the case I am assuming that when the ExecutorFilter thread
finishes its operations the data is copied back to shared memory and
then again to the IO processor thread memory for writing a response.
Is it right that this a problem partially solved with In-VM pipe? In
this case it would I am assuming it would be socket data to written to
pipe (in IO processor thread) and then read or copied straight to
ExecutorFilter thread (or something along those lines).
I hope this is clearer, using MINA would save me a lot of time, I could
use this saved time to contribute to furthering the goals of the
project. Also, because I am not in a rush, that time is available
immediately.
Regards,
Simon
Eero Nevalainen wrote:
Hello!
I haven't dug deep enough to say anything authoritative, but I think
you've the got the thread memory and shared memory sort of backwards.
To my understanding, "shared memory" generally means that the data is
in the Main memory (RAM) of the computer
(see http://en.wikipedia.org/wiki/Memory_(computers) )
where it can be accessed by every CPU. In contrast, "thread working
memory" does not need to accessible by other CPUs, so the java runtime
will make every effort to perform "thread working memory" instructions
in the CPU registries and cache.
(see http://en.wikipedia.org/wiki/Processor_register )
Copying between the CPU local memory and main memory is still
unavoidable if the data is too big to fit to what the CPU has. If you
still want to build something on top of java threads then I suggest
you read on user threads or "fibers".
-Eero Nevalainen
Steve Ulrich wrote:
Hi!
I don't think mina-list is the right list for this.
Some thoughts, anyway:
"shared memory" between threads should be synchronized somehow
(doesn't mean it has to be in a synchronized block), so it's a big
performance killer to synchronize all variables. If you need
synchronized variables read the documentation for the "volatile" flag
and the API for the atomic- and concurrency-packages will be usefull
as well.
If you implement your own "thread model" in a single thread, your
application won't scale very well to multi processor systems. A
simple form of this "thread model" is the Executor created by
"Executors.newSingleThreadExecutor()". But it's poison for
scalability!!!
My opinion: using some volatile flags, Locks and concurrency
collections at the right positions will surely do the trick and lead
to a better scalability. Even a little oversynchronisation will be
better than a "single thread thread model" ;-)
regards
Steve
Simon Funnell [mailto:[EMAIL PROTECTED] wrote:
Dear List,
This is not exactly Mina specific, its more general, but its close to
the problem Mina surrounds. I have been working on an approach to
concurrency and I have come to the point where the Java Thread model is
causing me problems. I would like to create my own threading model that
does away with shared memory and thread memory, so there is just shared
memory. My original idea was to use a single thread and implement my
own
threads within that thread. The difficulty with this is that there is
still copying from shared memory to thread working memory (as I
understand it). I would like to cut out this shared memory to thread
memory and back to shared memory copying. Is this possible?
Thanks for any replies.
Regards,
Simon
