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

Mistake #72's solution might not work #107

Open
mtfcd opened this issue Dec 20, 2024 · 0 comments
Open

Mistake #72's solution might not work #107

mtfcd opened this issue Dec 20, 2024 · 0 comments
Labels
erratum Erratum

Comments

@mtfcd
Copy link

mtfcd commented Dec 20, 2024

Describe the book error

The code in the book works because the updater goroutine sleeps for 1 second before acquiring the lock. This ensures that the Listener goroutines have time to acquire the lock and check if the condition is met. However, if the sleep is removed or reduced to a very short duration (e.g., time.Nanosecond), the code may not work as expected.

I believe there might be two reasons for this:

  1. The Updater goroutine competes with the Listener goroutines, preventing them from acquiring the lock.
  2. The two Listener goroutines compete with each other. For example, the f(15) goroutine might consistently succeed in acquiring the lock. After f(15) releases the lock, the Updater goroutine might acquire it, which could prevent the f(10) goroutine from ever getting the lock.
@mtfcd mtfcd added the erratum Erratum label Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
erratum Erratum
Projects
None yet
Development

No branches or pull requests

1 participant