Hi Lian, Good to hear that you are learning about StateFun, and I'd be happy to answer any of your questions while doing so :-) Perhaps in the future it would be best if you start a new email thread, so that it would be easier to spot your question.
The following is completely thread safe: final int seen = count.getOrDefault(0); count.set(seen + 1); The simple reason is that the functions are invoked one by one on a single OS thread, and different OS threads do not share function instances between them. In addition each OS thread would own a chunk of keys that only it can invoke. 2. Is there any scenario that the developers need to worry about > process/thread safety when using state? Few things here: * do not share mutable static variables without synchronization. * try to minimize/avoid doing long blocking calls. Use asynchronous API if applicable. 3. can I consider stateful functions as Flink operators so that all > operator related theories can be applied to stateful functions? > Absolutely yes. StateFun is built on-top of the DataStream API + some internal bits. > 4. Similarly, can we apply all theories of DataStream state to stateFun's > state? I'm not sure what do you mean by that, but at large yes. The main difference would be that We don't support state evolution with arbitrary state types, but strictly require Protocol Buffers for that. Good luck, Igal. On Sun, Oct 25, 2020 at 7:43 PM Lian Jiang <jiangok2...@gmail.com> wrote: > Hi, > > I am learning > https://ci.apache.org/projects/flink/flink-statefun-docs-release-2.2/getting-started/java_walkthrough.html > and wondering if the invoke function is thread safe for: > > final int seen = count.getOrDefault(0);count.set(seen + 1); > > From > https://ci.apache.org/projects/flink/flink-statefun-docs-release-2.2/concepts/logical.html > > "When an application starts, each parallel worker of the framework will > create one physical object per function type." > > It sounds like one function can be invoked by multiple workers at the same > time. The tutorial example > > indicates that the persistedValue can be process safe (cross multiple > workers) and thread safe (inside > > a worker, e.g. timer callback). > > > Could you please add some clarification on the questions below? > > 1. What's the design (briefly) for persisted state process/thread safety? > 2. Is there any scenario that the developers need to worry about > process/thread safety when using state? > > 3. can I consider stateful functions as Flink operators so that all operator > related theories can be applied to stateful functions? > > 4. Similarly, can we apply all theories of DataStream state to stateFun's > state? > > Appreciate very much! > > > Thanks > > Lian > > > On Sun, May 10, 2020 at 9:33 PM Tzu-Li (Gordon) Tai <tzuli...@apache.org> > wrote: > >> As others have mentioned already, it is true that method calls on >> operators >> (e.g. processing events and snapshotting state) will not concurrently >> happen. >> >> As for your findings in reading through the documentation, that might be a >> hint that we could add a bit more explanation mentioning this. >> Could you suggest where you'd probably expect to see this being mentioned, >> based on your readt-hrough? >> >> Cheers, >> Gordon >> >> >> >> -- >> Sent from: >> http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/ >> > > > -- > > Create your own email signature > <https://www.wisestamp.com/signature-in-email/?utm_source=promotion&utm_medium=signature&utm_campaign=create_your_own&srcid=5234462839406592> >
