Often, rather than changing the list you'll want some summary statistic about the list. total payroll or something like that. So that's trivial.
In other cases, you have a thread that depends on some other thread's result. Say a game engine with a list of positions. The render part needs to know the positions. rather than applying a transform to each element in place, apply the function as you traverse the list.
for(Thing* p; p; p = p->next){
render(transform(p));
}
(i know it's contrived, but that's the gist)
finally, you can be pretty sneaky with other structures. If you have a binary tree with infrequent edits, you'll get away with log2(height) new nodes rather than a whole tree. If performance is critical, this is less good, but a few hundred bytes here and there for all the other good stuff immutability gets you (other threads keep using the old tree) might be worth it.
A big part of it is trying to think about how to structure your code to take advantage of immutability. If you're already changing stuff all over the place, it's not going to help much. but if you plan ahead, usually, you can build the structure with the right values up front.
Going back to the list example, you've got some data coming in. rather than many passes making many lists, you have one thread that reads data, passes it to n helpers that do all the work, then it reassembles the answers into a list. I guess that's more concurrent than parallel, but i think it captures the essence of what you're looking for.
In other cases, you have a thread that depends on some other thread's result. Say a game engine with a list of positions. The render part needs to know the positions. rather than applying a transform to each element in place, apply the function as you traverse the list.
(i know it's contrived, but that's the gist)finally, you can be pretty sneaky with other structures. If you have a binary tree with infrequent edits, you'll get away with log2(height) new nodes rather than a whole tree. If performance is critical, this is less good, but a few hundred bytes here and there for all the other good stuff immutability gets you (other threads keep using the old tree) might be worth it.
A big part of it is trying to think about how to structure your code to take advantage of immutability. If you're already changing stuff all over the place, it's not going to help much. but if you plan ahead, usually, you can build the structure with the right values up front.
Going back to the list example, you've got some data coming in. rather than many passes making many lists, you have one thread that reads data, passes it to n helpers that do all the work, then it reassembles the answers into a list. I guess that's more concurrent than parallel, but i think it captures the essence of what you're looking for.