Changing the locking object inside @synchronized section

假装没事ソ 提交于 2019-11-29 07:10:54

Short answer: no, they won't properly lock/unlock, and such approaches should be avoided.

My first question is why you'd want to do something like this, since these approaches nullify the purposes and benefits of using a @synchronized block in the first place.

In your second example, once a thread changes the value of obj, every subsequent thread that reaches the @synchronized block will synchronize on the new object, not the original object. For N threads, you'd be explicitly creating N autoreleased objects, and the runtime may create up to N recursive locks associated with those objects. Swapping out the object on which you synchronize within the critical section is a fundamental no-no of thread-safe concurrency. Don't do it. Ever. If multiple threads can safely access a block concurrently, just omit the @synchronized entirely.

In your first example, the results may be undefined, and certainly not what you want, either. If the runtime only uses the object pointer to find the associated lock, the code may run fine, but synchronizing on nil has no perceptible effect in my simple tests, so again you're using @synchronized in a pointless way, since it offers no protection whatsoever.

I'm honestly not trying to be harsh, since I figure you're probably just curious about the construct. I'm just wording this strongly to (hopefully) prevent you and others from writing code that is fatally flawed, especially if under the assumption that it synchronizes properly. Good luck!

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!