Skip to content

fix: multithreading issue part 2#512

Merged
pankcuf merged 19 commits into
developfrom
fix/multithreading-issue-part-2
Sep 18, 2023
Merged

fix: multithreading issue part 2#512
pankcuf merged 19 commits into
developfrom
fix/multithreading-issue-part-2

Conversation

@pankcuf

@pankcuf pankcuf commented Aug 1, 2023

Copy link
Copy Markdown
Contributor

Issue being fixed or feature implemented

Fix: some thread-safety issues
Add disconnect reason entity

What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

@pankcuf pankcuf requested a review from a team August 1, 2023 12:16
- (void)updateAttributesFromSimplifiedMasternodeEntry:(DSSimplifiedMasternodeEntry *)simplifiedMasternodeEntry atBlockHeight:(uint32_t)blockHeight knownOperatorAddresses:(NSDictionary<NSString *, DSAddressEntity *> *)knownOperatorAddresses knownVotingAddresses:(NSDictionary<NSString *, DSAddressEntity *> *)knownVotingAddresses localMasternodes:(NSDictionary<NSData *, DSLocalMasternodeEntity *> *)localMasternodes {
if (self.updateHeight < blockHeight) {
NSAssert(simplifiedMasternodeEntry.updateHeight == blockHeight, @"the block height should be the same as the entry update height");
//NSAssert(simplifiedMasternodeEntry.updateHeight == blockHeight, @"the block height should be the same as the entry update height");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pankcuf Why commented?

@tikhop tikhop left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the PR looks good except the overuse of '@synchronized'. I don't think this is the solution to our multithreading issues.

double maxAmount = self.masternodeListRetrievalQueueMaxAmount;
if (!amountLeft) {
return self.store.masternodeListsAndQuorumsIsSynced;
@synchronized (self) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pankcuf I don't think @synchronized is a real solution, I personally against using @synchronized because it can lead performance decreasing and other "unknowns"

return 1;
} else {
return 0;
@synchronized (self.peerManager) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pankcuf I don't think @synchronized is a real solution, I personally against using @synchronized because it can lead performance decreasing and other "unknowns"

self.store.lastQueriedBlockHash = blockHash;
NSData *blockHashData = uint256_data(blockHash);
[self.store.masternodeListQueriesNeedingQuorumsValidated addObject:blockHashData];
@synchronized (self.store.masternodeListQueriesNeedingQuorumsValidated) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pankcuf I don't think @synchronized is a real solution, I personally against using @synchronized because it can lead performance decreasing and other "unknowns"

NSData *masternodeListBlockHashData = uint256_data(masternodeListBlockHash);
if ([neededMissingMasternodeLists count] && [self.store.masternodeListQueriesNeedingQuorumsValidated containsObject:masternodeListBlockHashData]) {
BOOL hasAwaitingQuorumValidation;
@synchronized (self.store.masternodeListQueriesNeedingQuorumsValidated) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pankcuf I don't think @synchronized is a real solution, I personally against using @synchronized because it can lead performance decreasing and other "unknowns"

if (uint256_eq(self.store.lastQueriedBlockHash, masternodeListBlockHash)) {
self.masternodeListDiffService.currentMasternodeList = masternodeList;
[self.store.masternodeListQueriesNeedingQuorumsValidated removeObject:masternodeListBlockHashData];
@synchronized (self.store.masternodeListQueriesNeedingQuorumsValidated) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pankcuf I don't think @synchronized is a real solution, I personally against using @synchronized because it can lead performance decreasing and other "unknowns"

@tikhop

tikhop commented Aug 2, 2023

Copy link
Copy Markdown
Contributor

In addition all tests are failing and it will be good to have them working again

@tikhop

tikhop commented Aug 2, 2023

Copy link
Copy Markdown
Contributor

Another minor issue is PR's title. We agreed a year ago to use conventional style.

@pankcuf pankcuf changed the title Fix/multithreading issue part 2 fix: multithreading issue part 2 Aug 29, 2023
@pankcuf

pankcuf commented Aug 29, 2023

Copy link
Copy Markdown
Contributor Author

@tikhop You claim that the use "@synchronized" leads to some kind of overhead. In general I agree with that point. But from my perspective, we must proceed from practical considerations and we have several alternatives:

  • to deal with periodic anonymous crashes related to the thread unsafety (pause this PR).
  • to proceed with this solution that uses @synchronized directive – It will not slowing down anything (merge this PR),
  • go deep into that story, and rewrite a half of dashsync to make everything more efficient (...).
    I decided to stick with the second option, as it seems to me the most reasonable under the current conditions.
    And there are several reasons for this:
  1. Because a small overhead is better than random crashes themselves.
  2. DashSync code itself uses a lot of @synchronized. Without resolving them, it is impossible to write a really good architecture.
  3. It seems to me that the task of implementing a more competent approach, in terms of orchestration of threads, is much closer to a rust solution than in DashSync. So it's just not worth it to rewrite DashSync.

Therefore, I suggest as follows, roll out the build from this feature branch and test it. If it's ok, then to merge it.

@pankcuf pankcuf merged commit dda76aa into develop Sep 18, 2023
@pankcuf pankcuf deleted the fix/multithreading-issue-part-2 branch November 10, 2023 16:27
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

Successfully merging this pull request may close these issues.

2 participants