You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently FactorizedTable is not a threadsafe class. In particular it has a merge function to merge multiple FactorizedTables that delegates the responsibility of thread safety, i.e., acquiring the locks, to the caller. This makes the code harder to read as one needs to figure out the call stack to find whether or not a lock has been acquired. It also leads to duplicated lock acquisition code in cases when the only reason the caller uses a mutex and lock is to ensure FactorizedTable::merge's safety (which is currently what happens on ResultCollectorSharedState::mergeLocalTable and the GDS RJOutputWriterVC code in my branch).
Instead FactorizedTable should be threadsafe itself by keeping an internal lock. Even if an outside lock is acquired this is fine and in some cases, as in RJOutputWriterVC, this can help us remove the duplicated locking code from the caller. So we should refactor this.
The text was updated successfully, but these errors were encountered:
Currently FactorizedTable is not a threadsafe class. In particular it has a merge function to merge multiple FactorizedTables that delegates the responsibility of thread safety, i.e., acquiring the locks, to the caller. This makes the code harder to read as one needs to figure out the call stack to find whether or not a lock has been acquired. It also leads to duplicated lock acquisition code in cases when the only reason the caller uses a mutex and lock is to ensure FactorizedTable::merge's safety (which is currently what happens on ResultCollectorSharedState::mergeLocalTable and the GDS RJOutputWriterVC code in my branch).
Instead FactorizedTable should be threadsafe itself by keeping an internal lock. Even if an outside lock is acquired this is fine and in some cases, as in RJOutputWriterVC, this can help us remove the duplicated locking code from the caller. So we should refactor this.
The text was updated successfully, but these errors were encountered: