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

Improve/Enhance Is(Self)Busy to handle nested busy scenarios better #3954

Open
StefanOssendorf opened this issue May 18, 2024 · 0 comments · May be fixed by #3982
Open

Improve/Enhance Is(Self)Busy to handle nested busy scenarios better #3954

StefanOssendorf opened this issue May 18, 2024 · 0 comments · May be fixed by #3982
Assignees

Comments

@StefanOssendorf
Copy link
Contributor

Currently Is(Self)Busy is only a bool. This must not change with respect to the public api.
But handling that bool should be instead an integer to count busyness and non busyness.
Something like the following would today end the "busyness" early eventhogh it's not expected/desired:

public void Foo()
{
  try
  {
    MarkAsBusy();
    // more locs
    Bar();
    // more locs
  }
  finally
 {
    MarkAsIdle();
 }
}

public void Bar()
{
  // Do stuff here
  MarkAsIdle();
}

With such a structure the busyness would end early. With an internal counter we could more easily handle the busy flag.
Something like this:

private int _isBusyCounter;

MarkAsBusy()
{
  Interlocked.Increment(ref _isBusyCounter);
  // Other stuff the implementation needs
}

MarkAsIdle()
{
  Interlocked.Decrement(ref _isBusyCounter);
  // Other stuff the implementation needs
}

With this as long as the dev ensure he's calling MarkBusy() and MarkIdle() in pairs the busy state will always be correct without worrying about where the method is used.

StefanOssendorf added a commit to Freelancingonupwork/csla that referenced this issue May 30, 2024
…-to-handle-nested-busy-scenarios-better/main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants