Would be good to mention the more "Kotliny" way of locking by using a mutex, since technically locking means blocking the thread, and also synchronized will not work when inside a coroutine.
hi Philipp, i would like to see a video about your story. How you became developer, how you got better and became such knowledgeable and proficient. Something about your mindset, your daily routine when you were at the beginning, 3 years into coding, 7 years and now. Thank you for everything you do :)
But collections in particular - that's a textbook example. Although a collection doesn't have to be a List. In fact, this example really calls for a Map, since the messages are indexed - looking an index up with indexOfFirst every time is a bit iffy. Could be a LinkedHashMap, if the order matters. I know it was only meant to illustrate the concept; consider it as a side remark, not criticism
I think a critical race condition that would break list-indices in the first Chatmanager example-code is only theoretical unless you add code to delete messages or change the order of messages in the list. Right now with only adding, indices are stable and working on them with multiple threads should not introduce any bug. Please correct me if I am wrong (but please give a reason and explain).
I agree since adding to the list will only append. Indices will break if messages are inserted by index and also by removed as you mentioned. So the first chat manager looks fine.
Hi Philipp. This is very interesting. I would have liked, if you run the code to see exactly where race conditions are at work. Maybe a follow up tutorial?
This is a good idea although synchronization comes with performance cost in increased latency. Theres also possibilities of deadlocks and resource contention. I'll be working on a small personal project to see how dealing with this in the real sense gets.
In this case if you're only ever adding to the end of the list and we're using a unique ID to find the index, then the index will always refer to same element, won't it? If there is no other code modifying the list I don't think we'd see a bug. A race condition that results in a bug could occur if we were moving elements around or deleting elements. Edit: I see that @StingerAJ pointed out the same thing.
I'm confused about why the index in `onMessageDeliveryStateChanged` would not be valid if all we are doing is adding to the message list. Are indices reevaluated every time a list is updated?
Would be good to mention the more "Kotliny" way of locking by using a mutex, since technically locking means blocking the thread, and also synchronized will not work when inside a coroutine.
hi Philipp, i would like to see a video about your story. How you became developer, how you got better and became such knowledgeable and proficient. Something about your mindset, your daily routine when you were at the beginning, 3 years into coding, 7 years and now. Thank you for everything you do :)
Good video, however i don't think the issue presented here is specific to lists, race conditions can also happen with any kind of mutable data.
True :)
But collections in particular - that's a textbook example. Although a collection doesn't have to be a List.
In fact, this example really calls for a Map, since the messages are indexed - looking an index up with indexOfFirst every time is a bit iffy. Could be a LinkedHashMap, if the order matters. I know it was only meant to illustrate the concept; consider it as a side remark, not criticism
Дякую за чудове пояснення.
For this scenarios I would use CopyOnWriteArrayList that already utilizes synchronized blocks for every write operation under the hood
I think a critical race condition that would break list-indices in the first Chatmanager example-code is only theoretical unless you add code to delete messages or change the order of messages in the list. Right now with only adding, indices are stable and working on them with multiple threads should not introduce any bug. Please correct me if I am wrong (but please give a reason and explain).
I agree since adding to the list will only append. Indices will break if messages are inserted by index and also by removed as you mentioned. So the first chat manager looks fine.
Hi Philipp. This is very interesting. I would have liked, if you run the code to see exactly where race conditions are at work.
Maybe a follow up tutorial?
Love this time format. More please!
This is a good idea although synchronization comes with performance cost in increased latency. Theres also possibilities of deadlocks and resource contention.
I'll be working on a small personal project to see how dealing with this in the real sense gets.
In this case if you're only ever adding to the end of the list and we're using a unique ID to find the index, then the index will always refer to same element, won't it? If there is no other code modifying the list I don't think we'd see a bug.
A race condition that results in a bug could occur if we were moving elements around or deleting elements.
Edit: I see that @StingerAJ pointed out the same thing.
Thanks Philipp, great content!! is it there a way to test the case when the race conditions happen?
I see huge progress in the insertion of advertising content
Thank you, for video. I think you could also mention about CopyOnWriteArrayList, that preferable for this kind of operations )
Can you also show how coroutine channels can be used to synchronize changes as well?
Good video, and is the main reason why I use Mutex objects to lock on coroutines
Question regarding the synchronized.
Does it not execute or add the execution in queue?
Hello, would you turn on "Thank you" option as well so we can contribute to your videos as well ? thanks :)
Content we pay our internet bill for :)
whats your android studio theme?
What theme you use ?
i would personally go with AtomicReference or Volatile
will this method work for methods marked as suspend? I think it's better to use Muxed
thanks for sharing
Sir, Android 11 factory reset data can recover?
I'm confused about why the index in `onMessageDeliveryStateChanged` would not be valid if all we are doing is adding to the message list. Are indices reevaluated every time a list is updated?
synchronized(this) should also do the job
Why not use volatile annotation over the messages list?
I use kotlins Mutex concept not javas syncronized in that case but both should work ❤
But Muted would mean you have to use suspend funs
true but that is my many case that courses concurrency issues.
wouldn't be better to use a State Flow instead or a Shared State Flow.
Is this going to work if you were using coroutines?
No, it won't work with coroutines, but you can find corresponding manual in official Kotlin docs named "Shared mutable state and concurrency".
Good
Hi Phillip, idk what happened in the last videos but the audio quality dropped, your voice sounds a little bit weird
Thank you I will check that with my editor
I would avoid synchronized with Kotlin.
goat
Philipp you are doing great content but something dies inside of me when I see those thumbnails >_
hahaha
Deadlock...