|
From: | Vladimir Sementsov-Ogievskiy |
Subject: | Re: [PATCH 5/6] co-shared-resource: protect with a mutex |
Date: | Sat, 15 May 2021 10:11:38 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 |
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-safetyFrom 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
[Prev in Thread] | Current Thread | [Next in Thread] |