15.05.2021 00:53, Emanuele Giuseppe Esposito wrote:
we want to get from shres here, after possible call to block_copy_task_shrink(),
as task->bytes may be reduced.
Ah right, I missed that. So I guess if we want the caller to protect
co-shared-resource, get_from_shres stays where it is, and
we want to get from shres here, after possible call to
block_copy_task_shrink(), as task->bytes may be reduced.
Ah right, I missed that. So I guess if we want the caller to protect
co-shared-resource, get_from_shres stays where it is, and put_
instead can still go into task_end (with a
14.05.2021 20:28, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 17:30, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021
Il ven 14 mag 2021, 16:10 Emanuele Giuseppe Esposito
ha scritto:
> > I'm not sure I like it since callers may still need coarser grained
> > locks to protect their own state or synchronize access to multiple
> > items of data. Also, some callers may not need thread-safety.
> >
> > Can the caller
On 14/05/2021 17:30, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at
14.05.2021 17:32, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote:
On 14/05/2021 16:26, Vladimir Sementsov-Ogievskiy wrote:
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito
wrote:
co-shared-resource is currently not thread-safe, as also
14.05.2021 17:10, Emanuele Giuseppe Esposito wrote:
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote:
co-shared-resource is currently not thread-safe, as also reported
in co-shared-resource.h. Add a QemuMutex because
On 12/05/2021 17:44, Stefan Hajnoczi wrote:
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote:
co-shared-resource is currently not thread-safe, as also reported
in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres
can also be invoked from
On 12/05/21 17:44, Stefan Hajnoczi wrote:
If we follow this strategy basically any data structure used
by coroutines needs its own fine-grained lock (like Java's Object base
class which has its own lock).
Maybe not all, but only those that use CoQueue? Interestingly, I was a
bit less okay
On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote:
> co-shared-resource is currently not thread-safe, as also reported
> in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres
> can also be invoked from non-coroutine context.
>
> Signed-off-by: Emanuele
On 10/05/21 13:40, Vladimir Sementsov-Ogievskiy wrote:
co-shared-resource is currently not thread-safe, as also reported
in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres
can also be invoked from non-coroutine context.
But it doesn't. It's called only from
10.05.2021 11:59, Emanuele Giuseppe Esposito wrote:
co-shared-resource is currently not thread-safe, as also reported
in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres
can also be invoked from non-coroutine context.
But it doesn't. It's called only from
co-shared-resource is currently not thread-safe, as also reported
in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres
can also be invoked from non-coroutine context.
Signed-off-by: Emanuele Giuseppe Esposito
---
util/qemu-co-shared-resource.c | 26 ++
14 matches
Mail list logo
