There is a simple way to fix the problem.
Considering that the only race condition that could occur is when the
selector thread tests the write queue and then change the OP_WRITE flag
to true, and when the writer queue add some new request in the queue,
and set the OP_WRITE to true, the solution
Le 11/11/12 8:19 AM, Julien Vermillard a écrit :
yes but the problem in fact is to lock the socket write flag
Is that an issue at all ? We can't set the socket flag while waiting for
the select() to complete, so it's done outside fo the select() call,
thus while the selectionLoop thread is
when the I/O selector code :
- queue.isEmpty() ?
- set write flag off
write thread code :
- queue.add(message)
- set write flag on
there is a concurrency issue there, the write thread can set the write flag
just between the two I/O selector instructions.
On Sun, Nov 11, 2012 at 8:59 AM,
Le 11/11/12 10:03 AM, Julien Vermillard a écrit :
when the I/O selector code :
- queue.isEmpty() ?
- set write flag off
write thread code :
- queue.add(message)
- set write flag on
Thanks for the heads up.
I had in mind the fact that the write thread queue should not set the
flag. The
does a simple lock on a quickly unlock resource between two thread is
really an issue ? sometimes a lock or a spin lock is much more efficient
than message passing around and thread wakeuping (context switching).
I think we should keep the lock and focus on the queue bypassing which is
probably
Le 11/11/12 11:02 AM, Julien Vermillard a écrit :
does a simple lock on a quickly unlock resource between two thread is
really an issue ? sometimes a lock or a spin lock is much more efficient
than message passing around and thread wakeuping (context switching).
I think we should keep the
Le 11/11/12 10:03 AM, Julien Vermillard a écrit :
when the I/O selector code :
- queue.isEmpty() ?
- set write flag off
write thread code :
- queue.add(message)
- set write flag on
There are 6 possible cases :
1) QIE, SWFOFF, QA, SWFON : OK
2) QIE, QA, SWFOFF, SWFON : OK
3) QIE, QA,
hmm I think the queue sync was added (by you?) because even if it's a
conncurent queue, the write registration could fail if a thead write in
the queue while the selector loop write it.
On Fri, Nov 9, 2012 at 11:24 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Hi,
I have a few comments
it's not a problem of writing it's a problem of removing the interested
write ops on the socket while another thread add a request in the queue.
On Sat, Nov 10, 2012 at 10:58 AM, Emmanuel Lécharny elecha...@gmail.comwrote:
Le 11/10/12 10:52 AM, Emmanuel Lécharny a écrit :
Le 11/10/12 9:28
I think a simple spin lock would be much faster than plain java lock,
because we have two thread sharing short time locked resource, the thread
wanting to lock can loop a little it will receive the lock very quickly. In
case of a java lock the thread will be candidate for context switching and
I'm
Le 11/10/12 8:42 PM, Julien Vermillard a écrit :
I think a simple spin lock would be much faster than plain java lock,
because we have two thread sharing short time locked resource, the thread
wanting to lock can loop a little it will receive the lock very quickly. In
case of a java lock the
yes but the problem in fact is to lock the socket write flag not the
queue which is obviously thread safe
On 11/10/12, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 11/10/12 8:42 PM, Julien Vermillard a écrit :
I think a simple spin lock would be much faster than plain java lock,
because we
Emmanuel Lécharny [mailto:elecha...@apache.org] wrote:
After a second (third ?) thought, sounds like trying to have only one
queue per IoProcessor is not really a good idea.
I like the idea of letting the IoProcessor handle the queue(s). The queue could
be seen as an IoProcessor internal
Hi!
I'm sceptical about it. Maybe you could design it in a way, that the
IoProcessor is replaceable, so one could test the behaviour.
Cons:
* Imagine a bunch of smaller write requests per session. Currently an
IoProcessor at least have a chance to optimize the writes by flushing all data
of
On 4/18/11 10:01 AM, Steve Ulrich wrote:
Hi!
I'm sceptical about it. Maybe you could design it in a way, that the
IoProcessor is replaceable, so one could test the behaviour.
And this is why I posted my suggestion on the mailing list :) My idea
might well be totally off base.
Cons:
*
D4n Outlook. This time with a better quotation... I hope
Emmanuel Lecharny [mailto:elecha...@gmail.com] wrote
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
socket can't accept any more writing.
Le Mon, 18 Apr 2011 10:26:42 +0200,
Emmanuel Lecharny elecha...@gmail.com a écrit :
On 4/18/11 10:01 AM, Steve Ulrich wrote:
Hi!
I'm sceptical about it. Maybe you could design it in a way, that
the IoProcessor is replaceable, so one could test the behaviour.
And this is why I posted my
On 4/18/11 12:13 PM, Steve Ulrich wrote:
D4n Outlook. This time with a better quotation... I hope
Emmanuel Lecharny [mailto:elecha...@gmail.com] wrote
Fair enough. But we can mitigate this risk on the IoProcessor too, by
pulling out of the queue all the messages for a session, until the
On 4/18/11 12:14 PM, Julien Vermillard wrote:
Le Mon, 18 Apr 2011 10:26:42 +0200,
Emmanuel Lecharnyelecha...@gmail.com a écrit :
On 4/18/11 10:01 AM, Steve Ulrich wrote:
Hi!
I'm sceptical about it. Maybe you could design it in a way, that
the IoProcessor is replaceable, so one could test
After a second (third ?) thought, sounds like trying to have only one
queue per IoProcessor is not really a good idea.
It brings little, and cost a lot. Let's get back to one session/one
writing queue.
Thanks for the good feedback, Steve !
--
Regards,
Cordialement,
Emmanuel Lécharny
20 matches
Mail list logo
