Re: [PATCH 5/6] co-shared-resource: protect with a mutex

[Emanuele Giuseppe Esposito]

> > > > > 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 boolean enabling it).
> > >
> > > honestly, I don't follow how it helps thread-safety
> >
> >  From my understanding, the whole point here is to have no lock in 
> > co-shared-resource but let the caller take care of it (block-copy).
> >
> > The above was just an idea on how to do it.
>
> But how moving co_put_to_shres() make it thread-safe? Nothing in 
> block-copy is thread-safe yet..
Sorry this is my bad, I did not explain it properly. If you look closely 
at the diff I sent, there are locks in a similar way of my block-copy 
initial patch. So I am essentially assuming that block-copy has already 
locks, and moving co_put_to_shres in block_copy_task_end has the purpose 
of moving shres "in a function that has a critical section".

> > > > > > > @@ -269,6 +270,7 @@ static void coroutine_fn 
> > > > > > > block_copy_task_end(BlockCopyTask *task, int ret)
> > > > > > >           bdrv_set_dirty_bitmap(task->s->copy_bitmap, 
> > > > > > > task->offset, task->bytes);
> > > > > > >       }
> > > > > > >       qemu_co_mutex_lock(&task->s->tasks_lock);
               ^^^ locks
> > > > > > > +    co_put_to_shres(task->s->mem, task->bytes);
> > > > > > >       task->s->in_flight_bytes -= task->bytes;
> > > > > > >       QLIST_REMOVE(task, list);
> > > > > > >       progress_set_remaining(task->s->progress,

                unlocks here (not shown in the diff)
         }

Hopefully now it is clear. Apologies again for the confusion.

Emanuele