commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [javaflow] - how to use continuation in JNI boundary
Date Sun, 21 Jan 2018 00:21:51 GMT
This does not remove the restriction on the synchronization - that still
The thread could do something else during the wait - but that's another

There just is not automatic suspend on wait.
And it begs the question how such a thing would/should look like.

I am not saying this isn't something that could be interesting to
investigate - but this is just not what javaflow is.
The current javaflow implementation is about state storing and restoring -
not scheduling and pooling.

While you could improve thread usage by implementing thread re-use during
wait, the big problem will still always be the synchronized code.
So it really feels like you are trying to solve a problem from the wrong

Anyway - my 2 cents.
Take them or leave 'em ;)

On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto <> wrote:

> It is absolutely not true. If a coroutine  execute
> synchonized(lock){ lock.wait() }
> the lock.wait blocks the thread. Why i have to block the thread if thread
> can running other corotuines in the while?
> lock.wait must supend the coroutine and resuming another coroutine
> 2018-01-21 0:23 GMT+01:00 Torsten Curdt <>:
> > I am sorry but I must be missing something here.
> >
> > The code uses synchronization blocks and mutexes to explicitly make sure
> > threads don't interfere which each other.
> > This restriction will be there because of resource sharing and the java
> > memory model.
> > Instrumenting wait/notify cannot magically remove that restriction.
> >
> > Based on queuing theory you can move your bottleneck to your mutexes -
> but
> > that's about it.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message