```@Composable @Deprecated("Example with bug") fun ListWithBug(myList: List<String>) { var...

# compose

[Peng Wang]

@Composable
@Deprecated("Example with bug")
fun ListWithBug(myList: List<String>) {
    var items = 0

    Row(horizontalArrangement = Arrangement.SpaceBetween) {
        Column {
            for (item in myList) {
                Text("Item: $item")
                items++ // Avoid! Side-effect of the column recomposing.
            }
        }
        Text("Count: $items")
    }
}

I don't know why this code has thread-safe problem, can anyone explain ? https://developer.android.google.cn/jetpack/compose/mental-model#parallel

[Albert Chang]

It's explained before:

Composable functions can run in parallel

This optimization means a composable function might execute within a pool of background threads.

Compose UI isn't multi-threaded now but it can be in the future.

[Peng Wang]

Thanks for your answer，but in the above code, why does items++ run on multiple threads? items++ is not in a Composable, but just in a for-loop

[zokipirlo]

If for loop can run parallel, then items is changed from multiple threads. Just use forEachIndexed I guess in that case.

[Peng Wang]

Loop run parallel ? I don't think this is what Compose can do

[Albert Chang]

ListWithBug, Row, Column are all composables. The lambdas (content parameter) you passed to Row and Column are also composables.

[Peng Wang]

But items++ always run in one composable, so why thread unsafe ? I can understand if items++ in the for loop is wrapped in a composable, but it isn't now

[Albert Chang]

Text("Count: $items") can be run in another thread.

[Peng Wang]

So what the code wants to express is that Text and Column are parallel , not items++ is parallel ?

[Peng Wang]

Column is inline right？it can't be in parallel with Text

[Albert Chang]

I think the code is mainly intended to show that you should avoid side effects in your composables as it is incorrect even without multi-threaded composition. Multi-threaded composition just makes it "more" wrong.

[Albert Chang]

As I said before,

The lambdas (content parameter) you passed to Row and Column are also composables.

[Sean McQuillan [G]]

Author here. The intention is to show that each restart scope may be run on a new thread. So the write in column is not thread safe with the read in row

[Sean McQuillan [G]]

That said there's not currently multithreading and both are scopes are now inline so actually triggering this fault with this code would be hard ☺️

[Sean McQuillan [G]]

But in general code of this style is unsafe in compose (due to regular var write in lambda capture)

[Sean McQuillan [G]]

While here, it's worth saying that writing a MutableState is thread safe

[Sean McQuillan [G]]

Is there another (very simple) example that'd show this better?