Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thread safety #74

Open
9 of 11 tasks
jmirabel opened this issue Oct 19, 2018 · 0 comments
Open
9 of 11 tasks

Thread safety #74

jmirabel opened this issue Oct 19, 2018 · 0 comments

Comments

@jmirabel
Copy link
Contributor

jmirabel commented Oct 19, 2018

As of now, HPP can only be used with a single thread. Here are some thoughts to add thread safety.

Inside hpp-pinocchio

Except for class Device, which will handle all the thread safety work, I think there is relatively little work to be done.

  • Device:
    • move relevant member in a Data class.
    • make a vector of this Data and create a DeviceLock class which locks one Data.
    • change relevant methods API to accept a DeviceLock.
  • Joint:
    • currentTransformation
    • jacobian
    • bounds management (although we could say that no thread safety is required for this).
  • Frame:
    • currentTransformation
    • jacobian
  • ExtraConfigSpace:
    • bounds management (although we could say that no thread safety is required for this).
  • Gripper
  • functions in configuration.hh.
  • CollisionObject:
    • getTransform and getFclTransform
    • fcl
    • move (can stay thread-unsafe).
  • CenterOfMassComputation:
    • add compute (..., se3::Data). Access to result can be done with data.
  • Body
  • LieGroup related class will voluntarily stay not thread-safe.
  • Urdf loading will of course be not thread-safe.

Packages that depends on hpp-pinocchio

The impact on dependent packages should also not be very important. Something like replacing:

device->currentConfiguration(q);
device->computeForwardKinematics();
joint->jacobian();

into

DeviceLock lock = device->lock();
device->currentConfiguration(q, lock.data());
device->computeForwardKinematics(lock, lock.data());
joint->jacobian(lock.data());
lock.release(); // Or destroy the object to release

or

DeviceDataLock deviceData = device->acquireData();
deviceData->currentConfiguration(q);
deviceData->computeForwardKinematics();
joint->jacobian(deviceData);
deviceData.release(); // Or destroy the object to release

The first is more interesting as it gives to users the opportunity to handle tread management by themselves.

device->lock() is blocking only if all the internal Data are already locked. This should have very little impact on the single-thread case as the same data will be acquired. On multi-threaded cases, it may happen that we re-compute the kinematics for the same configuration if two different data are returned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant