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

[Emanuele Giuseppe Esposito <eesposit@redhat.com>]

>>>>> 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