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

acquire lock in addEdges() #5479

Merged
merged 3 commits into from
May 20, 2020
Merged

acquire lock in addEdges() #5479

merged 3 commits into from
May 20, 2020

Conversation

parasssh
Copy link
Contributor

@parasssh parasssh commented May 20, 2020

Fixes DGRAPH-1332


This change is Reviewable

Copy link
Contributor

@martinmr martinmr left a comment

Choose a reason for hiding this comment

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

Reviewed 1 of 1 files at r1.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @manishrjain, @parasssh, and @vvbalaji-dgraph)


worker/executor.go, line 85 at r1 (raw file):

	defer e.RUnlock()
	for _, ch := range e.predChan {
		close(ch)

is this the close you are referencing in your comment?

Why is the read lock being used here?


worker/executor.go, line 126 at r1 (raw file):

	}

	// Lock() in case the channel gets closed from underneath us.

I am still not clear from this comment how locking will prevent us from sending to a closed channel. Can you expand the comment a little bit?

Copy link
Contributor Author

@parasssh parasssh left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @manishrjain, @martinmr, and @vvbalaji-dgraph)


worker/executor.go, line 85 at r1 (raw file):

Previously, martinmr (Martin Martinez Rivera) wrote…

is this the close you are referencing in your comment?

Why is the read lock being used here?

Yes, this close.

Not sure why read lock was acquired here. Presumably


worker/executor.go, line 126 at r1 (raw file):

Previously, martinmr (Martin Martinez Rivera) wrote…

I am still not clear from this comment how locking will prevent us from sending to a closed channel. Can you expand the comment a little bit?

We will acquire Lock and so have exclusive access. The shutdown() method above will not be able to close the channel since it requires a ReadLock() and will block until we are done here.
The e.getChannel() method creates a channel for that attr if none exists and so the sending on the channel should succeed.

==
May be better way would be to just check here for e.Closer.HasBeenClosed in a non-blocking way and return from here.

Copy link
Contributor Author

@parasssh parasssh left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @manishrjain, @martinmr, and @vvbalaji-dgraph)


worker/executor.go, line 85 at r1 (raw file):

Previously, parasssh wrote…

Yes, this close.

Not sure why read lock was acquired here. Presumably

The comment was incomplete.

Yes, this close is what I am referring to.
The ReadLock is presumably acquired to close the channel.

Copy link
Contributor Author

@parasssh parasssh left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @manishrjain, @martinmr, and @vvbalaji-dgraph)


worker/executor.go, line 126 at r1 (raw file):

Previously, parasssh wrote…

We will acquire Lock and so have exclusive access. The shutdown() method above will not be able to close the channel since it requires a ReadLock() and will block until we are done here.
The e.getChannel() method creates a channel for that attr if none exists and so the sending on the channel should succeed.

==
May be better way would be to just check here for e.Closer.HasBeenClosed in a non-blocking way and return from here.

Nevermind. Acquiring Lock here will result in deadlock since getChannel() also needs a lock.
Need to think about a different solution.

Copy link
Contributor

@martinmr martinmr left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @manishrjain, @martinmr, @parasssh, and @vvbalaji-dgraph)


worker/executor.go, line 126 at r1 (raw file):

Previously, parasssh wrote…

Nevermind. Acquiring Lock here will result in deadlock since getChannel() also needs a lock.
Need to think about a different solution.

I think this works if you create and call a version of getChannel that assumes the lock has already been acquired (there are methods to assert this I believe).

Copy link
Contributor

@martinmr martinmr left a comment

Choose a reason for hiding this comment

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

:lgtm:

Reviewed 1 of 1 files at r2.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @manishrjain, @parasssh, and @vvbalaji-dgraph)


worker/executor.go, line 90 at r2 (raw file):

// getChannelUnderLock obtains the channel for the given pred. It must be called under e.Lock().
func (e *executor) getChannelUnderLock(pred string) (ch chan *subMutation) {

This is only used once so I don't think you need to rename it. Just the comment should be enough.

@parasssh parasssh merged commit 1e2f0e7 into master May 20, 2020
@parasssh parasssh deleted the paras/sentry_exec branch May 20, 2020 17:45
parasssh pushed a commit that referenced this pull request May 20, 2020
@parasssh parasssh restored the paras/sentry_exec branch May 20, 2020 18:18
parasssh pushed a commit that referenced this pull request May 20, 2020
dna2github pushed a commit to dna2fork/dgraph that referenced this pull request Jul 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants