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

[Vladimir Sementsov-Ogievskiy]

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


Hm. Understand now. If you go this way, I'd better add a critical section and 
keep shres operations where they are now. We don't have shres operation in task 
creation, so should not have in task finalization. Shres operations are kept in 
seperate. It probably not bad to refactor it to make shres operations as a part 
of task manipulation functions, but it would require more accurate refactoring, 
simpler is to keep it as is.


--
Best regards,
Vladimir