 |
 |
Thanks very much for the reviews so far. Concerning the thread-safety, I had considering this but concluded it was safe: given that once the semaphore is posted the only other access to syncWait in addition to the reset to nullptr would be through a concurrent call to Ref(). Ref() with negative value would be incorrect usage, since refCount<=0, and Ref() with positive would mean that the caller of Serialize() could not expect refCount to be zero after Serialize() returns, so I'd thought that incorrect usage too. But considering your point, it seems clearly to be a better approach: more robust, because of fewer assumptions and no extra locking cost. I understand it keeps the meaning of Serialize() to be "all ref counts already added at entry are guaranteed to have been removed at call exit", leaving it up to the caller to draw assumptions about whether the refCount will be zero. [I've updated the patch!] As noted it is not safe to call Serialize() concurrently (some may block indefinitely), but this is not required by current usage. -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/1996#issuecomment-1504891699 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1