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

Misleading exercice solution ch2, ex4 ? #37

Open
cmhteixeira opened this issue Jul 27, 2018 · 1 comment
Open

Misleading exercice solution ch2, ex4 ? #37

cmhteixeira opened this issue Jul 27, 2018 · 1 comment

Comments

@cmhteixeira
Copy link

I believe the solution introduces a race condition when there are more than 1 producer threads.
While the exercise describes only 1 producer thread, I would say it is still a bit misleading for the reader (if I am correct of course.).
Do you agree?

val producer = thread {
    var x = 0
    while (x < 15) {
      if (syncVar.isEmpty) {
        syncVar.put(x)
        x = x + 1
      }

    }
  }
class SyncVar[T] {

    private var empty: Boolean = true

    private var x: T = null.asInstanceOf[T]


    def put(x: T): Unit = this.synchronized {
      if (!empty) throw new Exception("must be empty")
      else {
        empty = false
        this.x = x
      }
    }

    def isEmpty = synchronized {
      empty
    }

[not shown code]

  }

The call to methods isEmpty and put(x:T) is synchronized. However on the producer thread, they are called on separate lines. Is the following possible:

  1. Some producer Thread-1 calls the method isEmpty, obtaining the monitor of the syncVar instance.
  2. The isEmptymethod returns true.
  3. The producer Thread-1 releases the monitor over the syncVar instance.
  4. Some other producer Thread-2 calls the same method isEmpty on the same syncVar instance.
  5. It also obtains the value of true.
  6. Producer Thread-2 calls method put(x:T), obtaining the monitor, and effectively inserting a value.
  7. Producer Thread-1 calls method put(x:T), obtains the monitor, but because the syncVar variable x is no longer empty, due to step 6, if throws an exception.
@axel22
Copy link
Member

axel22 commented Aug 28, 2018

Hi Carlos,

Thank you for your post! You are indeed correct that the scenario you describe can happen.
One possible workaround could be to unify isEmpty and put into a single method.

However, since this exercise is explicitly designed to demonstrate that busy waiting is detrimental, a single thread was assumed for simplicity.

But, to ask the reader to redesign the SyncVar API to support multiple producers would be an interesting open-ended question.

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

2 participants