This does not remove the restriction on the synchronization - that still
exists.
The thread could do something else during the wait - but that's another
story.
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
end.
Anyway - my 2 cents.
Take them or leave 'em ;)
On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto <
cristian.lorenze...@gmail.com> 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 <tcu...@vafer.org>:
>
> > 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.
> >
>
