How is the HandTracking in Happy Beam avoiding data racing?

I am new to learning about concurrency and I am working on an app that uses the HandTrackingProvider class.

In the Happy Beam sample code, there is a HearGestureModel which has a reference to the HandTrackingProvider() and this seems to write to a struct called HandUpdates inside the HeartGestureModel class through the publishHandTrackingUpdates() function. On another thread, there is a function called computeTransformofUserPerformedHeartGesture() which reads the values of the HandUpdates to determine whether the user is making the appropriate gesture.

My question is, how is the code handling the constant read and write to the HandUpdates struct?

Answered by Vision Pro Engineer in 808242022

Hello @ericD_TRI

The HeartGestureModel class is marked with @MainActor and thus requires all it's method invocations to be on the main actor.

The call from the update block on the RealityView in HappyBeamSpace is also marked at @MainActor so it is also running on the main actor. When it calls computeTransformOfUserPerformedHeartGesture() it will be on the main actor already. That function is on the main actor as well (because it's type HeartGestureModel) is marked with @MainActor.

So all these calls are serialized on the main actor.

Please let me know if you have any more questions.

Accepted Answer

Hello @ericD_TRI

The HeartGestureModel class is marked with @MainActor and thus requires all it's method invocations to be on the main actor.

The call from the update block on the RealityView in HappyBeamSpace is also marked at @MainActor so it is also running on the main actor. When it calls computeTransformOfUserPerformedHeartGesture() it will be on the main actor already. That function is on the main actor as well (because it's type HeartGestureModel) is marked with @MainActor.

So all these calls are serialized on the main actor.

Please let me know if you have any more questions.

How is the HandTracking in Happy Beam avoiding data racing?
 
 
Q