I read now Loom project is thinking to do exactly what i proposed. But when
it will be available? uhmmm i think i could require years...
I dont know , maybe i could patch the instrumenter
2018-01-21 1:21 GMT+01:00 Torsten Curdt <tcu...@vafer.org>:
> 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.
> > >
> >
>
