Java Threads are my problem.

[Simon Funnell <si...@googlemail.com>]

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

Re: Java Threads are my problem.

[Simon Funnell <si...@googlemail.com>]

Thanks again,

I think I have found what I am looking for, I will summarise and leave 
the list for the moment but I hope in the future it will be useful the 
project. My questions can be somewhat answered by telling you that in 
general I am on the right tracks and there are various implementations 
of the JVM that may provide optimizations. It requires more study.

I have designed (not built) a framework very similar to MINA however one 
of my aims was to make synchronization an inherent part of the design, 
i.e. remove any cases that required you to explicitly synchronize on a 
particular object. The idea is to factor out any component code that 
deals with 'locking' so the developer does not have to worry about 
making it 'thread safe'.

At the moment I am trying to find out where it will plug in, I will come 
back when I have something more tangible. I have enjoyed watching this 
project grow over the years, keep up the good work.

Simon


Emmanuel Lecharny wrote:
> Simon Funnell 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?
> Some good pointers :
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/
> http://www.javaconcurrencyinpractice.com/
> http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html
>
> FYI, MINA is a "network application framework which helps users 
> develop high performance and high scalability network applications 
> easily.". Nothing related to you needs, AFAIK.
>
> Please let this mailing list focused on MINA related questions.
>
> Thanks !
>
>

Re: Java Threads are my problem.

[Emmanuel Lecharny <el...@apache.org>]

Simon Funnell 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?
Some good pointers :

http://www.cs.umd.edu/~pugh/java/memoryModel/
http://www.javaconcurrencyinpractice.com/
http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

FYI, MINA is a "network application framework which helps users develop 
high performance and high scalability network applications easily.". 
Nothing related to you needs, AFAIK.

Please let this mailing list focused on MINA related questions.

Thanks !


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: AW: Java Threads are my problem.

[Eero Nevalainen <ee...@indagon.com>]

Simon Funnell wrote:
> 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.

Could you cite the exact source on which you base this interpretation. A 
short google on: java "thread memory" yielded me these two articles
http://www.developer.com/java/article.php/951051
http://www.javaperformancetuning.com/news/qotm030.shtml
I think the interpretation in both of these is that the "thread memory" 
is the copies in the CPU cache and registries. The CPU will make these 
copies when accessing the data even when it is in "shared memory"

> 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?

I think this is the case. Note however that the ExecutorFilter is by no 
means mandatory. I am using MINA without the ExecutorFilter to avoid one 
layer of context switch / copying.

> 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.

I think so, yes. I think MINA puts all outgoing writes in queue. I 
didn't check how the queues are drained, but the queuing is pretty much 
mandatory anyway if multiple threads can write to an IoSession. Maybe 
some MINA guru can tell how this works exactly?

> 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:simonfunnell@googlemail.com] 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
>>>
>>
>>
> 

Re: AW: Java Threads are my problem.

[Simon Funnell <si...@googlemail.com>]

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:simonfunnell@googlemail.com] 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
>>
>
>

Re: AW: Java Threads are my problem.

[Eero Nevalainen <ee...@indagon.com>]

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:simonfunnell@googlemail.com] 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
> 

AW: Java Threads are my problem.

[Steve Ulrich <st...@proemion.com>]

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:simonfunnell@googlemail.com] 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

Re: Java Threads are my problem.

[Mark Webb <el...@gmail.com>]

You are right.  This is not MINA-specific.  Not sure what you are trying to
accomplish here with MINA.



On Sun, Jun 22, 2008 at 9:59 PM, Simon Funnell <si...@googlemail.com>
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
>