Go Mutex Tutorial

Рет қаралды 21,543

Күн бұрын

👨‍💻 For the price of a ☕ every month, sign up and gain access to a growing list of premium courses on my site - tutorialedge.net/pricing/ 👩‍💻
● SUBSCRIBE to see more of my Videos & hit that LIKE button to support the channel!
In this tutorial, we will be looking at race conditions and how you can avoid them using mutexes within your Go programs!
‎● My Twitter ► ⁦‪ / elliot_f
‎● My Website ► tutorialedge.net

Пікірлер: 24

@alexplom5958 4 жыл бұрын

Really good that you explain how mutexes work. For those that want to check more you can find Optimistic vs Pessimistic concurrency. Keep up the good job

@abubelal2553 4 жыл бұрын

Another brilliant video 👍

@AntonyMapfumo 4 жыл бұрын

Nice explanation. Thank you.

@vic_shine 4 жыл бұрын

Nice! Thanks a lot!

@user-qk4tx9jc4m 3 жыл бұрын

great video!!!

@marvinottley5539 3 жыл бұрын

With regard to the wait group variable, it's a bit confusing to pass it to the function. Would it be better to incretent, use the wg.Add(1) above each function, and then, decrement wg.Done() withing each function as the function is about to exit?

@zuowang5481 Жыл бұрын

Is there a way to force the withdrawal be handled before handling the deposit? not using go routine I guess?

@oliverkaunds 3 жыл бұрын

Excellent Video!! Vikings seem to have come a long way from being warriors to GoLang Programmers.

@101graffhead 2 жыл бұрын

i thought channels were used for these kind of situations in go, i am a little confused now, when to use what.

@hastley64 Жыл бұрын

the code works perfectly fine without the mutexes. why?

@PatricPuola Жыл бұрын

Balance is modified directly. A more accurate scenario to the original diagram would be to have a getBalance function that returns the balance as value (not pointer) that is written over the original balance. Maybe add some time.sleep() to simulate delay betwen retrieval and the write operation.

@lelandaure Жыл бұрын

excuse me, sir. Why is the deposit happening first and then the withdrawing? shouldnt go routines be an unexpected order? O.o

@humanbeing8216 2 жыл бұрын

❤️

@mhmm2005 2 жыл бұрын

@TutorialEdge am I right? If we use only wait group, without mutex , it works properly

@jeremychevalier5831 5 күн бұрын

No. The whole point of the mutex is to prevent multiple processes from accessing process critical variables at the same time. Wait just waits until x things have been done. It won't prevent the scenario he laid out at the beginning. The problem is if they happen at the same time, it could be: Withdraw reads 1000 Deposit reads 1000 Deposit writes 1500 Withdraw writes 300 A mutex forces access to only one reader, so: Withdraw reads 1000 Withdraw writes 300 Deposit reads 300 Deposit writes 800 These could happen in either order, but the entire process is finished before the other function is allowed access

@prathamkesarkar 4 жыл бұрын

Make more GO language videos

@guents 3 жыл бұрын

Is it me or the bank example is quite badly explained? If the second process subtracts 700 from 1000 , while the first one adds 500, he might actually get 1500 and still pay the mortgage. There is no initial balance of 700, that's where you lost me. Maybe u wanted to say that the mortgage was the first process, it read 1000, then the second process read also 1000 and added 500, then the first one reset the balance to 1000-700. In that cause it would make sense, but i think you mixed the process order.

@Tutorialedge 3 жыл бұрын

I have just rewatched this and it seems I have misspoken and said "initial balance of £700" when I meant to say "initial balance of £1000". To avoid any doubt/confusion, the text version of this tutorial has the correct flow - tutorialedge.net/golang/go-mutex-tutorial/ Thanks for highlighting this friend!

@guents 3 жыл бұрын

@@Tutorialedge Hey, thanks the content and for the reply. I think what's not clear is the order of writes. Say we have routine 1 (R1) and routine 2 (R2). I guess the order you are considering is: 1: R1.read(1000), 2: R2.read(1000), 3: R1.write(1500), 4: R2.write(300). However, the text suggests the following order: 1: R1.read(1000), 2: R2.read(1000), 3: R2.write(300), 4: R1.write(1500), cause you are saying that R2 read it before R1 wrote, but then R2 wrote it immediately (without specifying that it was after R1 wrote).

@NinoM4sterChannel 4 жыл бұрын

can you defer(mutex.Unlock())?

@jeremychevalier5831 5 күн бұрын

Yes

@kaihendry 4 жыл бұрын

Didn't quite grok the two that you added here kzfaq.info/get/bejne/mdB9l7iey-C1h6c.html

@Tutorialedge 4 жыл бұрын

WaitGroups in Go are essentially counters. They start at 0 and we increment for the number of Goroutines we want to block for. In this instance we had 2 goroutines, deposit and withdraw that we wanted to ensure finished execution so we added 2 to the WaitGroup counter! I have a text + video tutorial on WaitGroups which can be found here: tutorialedge.net/golang/go-waitgroup-tutorial/