My name is Ștefan Cîrlig, but I go by Steve Hook. I love sharing my Software Engineering experience through different kinds of stories and creative videos, to help others with their careers.
Like I promised, today I'm launching the Steve Hook Academy mentorship program. It's a small step towards making Education better, that also rewards my invested time and effort. 🎓
If you're an individual just playing with the Go programming language, or thinking seriously about making a career change, I have good news for you. I want to become your personal mentor. No bullshit, I will personally guide and help you through your journey. 👨💻
Today is still a very good time to become a Go professional and run the market while it's still pretty young and small. If you want to become a Go professional today, go ahead and schedule a call with me, where we can talk some real business. 📞
Like I said before, I want to start doing Go Programming 1:1 Mentorship sessions and I need your input on how to make the best out of it. So here's a small Google Form you can fill in to help me out make a final decision 😇
Another Code Time about Concurrency in Go. As Go developers, we all know Atomics and Mutexes both can be used to prevent Race Conditions, and they both provide ways to make sure our Go programs execute correctly. The question is, can we mix the 2 primitives to achieve Correctness? What do you think will be the result of this program when executed with the -race flag?
▶️ go run -race main.go
1️⃣ Race Condition Print → count: 100000 2️⃣ No Race Condition Print → count: 100000 3️⃣ Race Condition Print → count: anything up to 100000 4️⃣ Race Condition No Race Condition Print → count: anything up to 100000
In concurrent computing deadlocks can happen for various reasons, most of which fall under 4 conditions also known as the Coffman Conditions ⬇️
1️⃣ CIRCULAR WAIT When at least 2 processes/tasks wait on each other to release the lock on the resource they hold, thus causing the condition when no process can neither release the lock they are holding, nor acquire the lock of the other process that has not yet been released. Thus causing all processes to be in a freezing or infinite waiting state also known as a deadlock
2️⃣ MUTUAL EXCLUSION When 2 or more processes/tasks try to acquire the lock on an exclusive (non-shareable) resource, while the process holding the lock for an indefinite period of time has not yet released it. Meaning only 1 process can access the resource at a time, thus causing the rest of the processes to deadlock
3️⃣ HOLD & WAIT When 2 or more processes/tasks wait for another process to release the lock it’s holding on a resource based on a condition that is never satisfied, thus causing the lock to never be released therefore causing all the waiting processes to deadlock or wait on a condition that is never met
4️⃣ NO PREEMPTION When a process/task at some point will execute a non-preemptive (uninterruptible computation) causing the current thread to be blocked for as long as the computation takes place, which can also be indefinite, thus causing the rest of the processes/tasks to indefinitely wait on the thread to become available therefore causing a deadlock on the thread manager
Stay tuned for the next Concurrency video, which will demonstrate all of these and so much more 💪
Feels good to be back after some time taken off. I'll start things slow with a good old Code Time post. While slices are a simple and useful data structure in Go, they can give you a headache, if you're not aware of their internals. So what's it going to be? 🤔
Howdy gents, Long time no see. What do y’all think about a new video series “I refactor your code”, where I will receive a bunch of Go code from you and make a video on refactoring it?
Let me know your opinions. I think this would be something cool and a learning experience for many people 👊
Back with another quiz. This time around, let's see what's your experience with Mutex Lock Starvation. Let's imagine both of the snippets below run in their own go routines and they receive the same instance of Mutex. Which snippet will successfully acquire the Mutex Lock more often? 🤔
Steve Hook
PING
3 months ago | [YT] | 1
View 0 replies
Steve Hook
Like I promised, today I'm launching the Steve Hook Academy mentorship program. It's a small step towards making Education better, that also rewards my invested time and effort. 🎓
If you're an individual just playing with the Go programming language, or thinking seriously about making a career change, I have good news for you. I want to become your personal mentor. No bullshit, I will personally guide and help you through your journey. 👨💻
Today is still a very good time to become a Go professional and run the market while it's still pretty young and small. If you want to become a Go professional today, go ahead and schedule a call with me, where we can talk some real business. 📞
academy.steevehook.com/
3 years ago | [YT] | 8
View 0 replies
Steve Hook
Like I said before, I want to start doing Go Programming 1:1 Mentorship sessions and I need your input on how to make the best out of it. So here's a small Google Form you can fill in to help me out make a final decision 😇
forms.gle/ynrQAxQroBwBPSkv5
#golang
3 years ago (edited) | [YT] | 2
View 0 replies
Steve Hook
I’m thinking more seriously about 1:1 mentorship on Go programming language. Hit that like if that’s you 🤙
3 years ago | [YT] | 3
View 0 replies
Steve Hook
Another Code Time about Concurrency in Go. As Go developers, we all know Atomics and Mutexes both can be used to prevent Race Conditions, and they both provide ways to make sure our Go programs execute correctly. The question is, can we mix the 2 primitives to achieve Correctness? What do you think will be the result of this program when executed with the -race flag?
▶️ go run -race main.go
1️⃣
Race Condition
Print → count: 100000
2️⃣
No Race Condition
Print → count: 100000
3️⃣
Race Condition
Print → count: anything up to 100000
4️⃣
Race Condition
No Race Condition
Print → count: anything up to 100000
#code_time #golang #steevehook #concurrency
3 years ago | [YT] | 11
View 1 reply
Steve Hook
Keeping up with the Matrix be like 😎
4 years ago | [YT] | 5
View 0 replies
Steve Hook
In concurrent computing deadlocks can happen for various reasons, most of which fall under 4 conditions also known as the Coffman Conditions ⬇️
1️⃣ CIRCULAR WAIT
When at least 2 processes/tasks wait on each other to release the lock on the resource they hold, thus causing the condition when no process can neither release the lock they are holding, nor acquire the lock of the other process that has not yet been released. Thus causing all processes to be in a freezing or infinite waiting state also known as a deadlock
2️⃣ MUTUAL EXCLUSION
When 2 or more processes/tasks try to acquire the lock on an exclusive (non-shareable) resource, while the process holding the lock for an indefinite period of time has not yet released it. Meaning only 1 process can access the resource at a time, thus causing the rest of the processes to deadlock
3️⃣ HOLD & WAIT
When 2 or more processes/tasks wait for another process to release the lock it’s holding on a resource based on a condition that is never satisfied, thus causing the lock to never be released therefore causing all the waiting processes to deadlock or wait on a condition that is never met
4️⃣ NO PREEMPTION
When a process/task at some point will execute a non-preemptive (uninterruptible computation) causing the current thread to be blocked for as long as the computation takes place, which can also be indefinite, thus causing the rest of the processes/tasks to indefinitely wait on the thread to become available therefore causing a deadlock on the thread manager
Stay tuned for the next Concurrency video, which will demonstrate all of these and so much more 💪
#golang #steevehook #steevehook_mini
4 years ago (edited) | [YT] | 6
View 2 replies
Steve Hook
Feels good to be back after some time taken off. I'll start things slow with a good old Code Time post. While slices are a simple and useful data structure in Go, they can give you a headache, if you're not aware of their internals. So what's it going to be? 🤔
✅ 1
✅ 3
#code_time #golang #steevehook
4 years ago | [YT] | 9
View 2 replies
Steve Hook
Howdy gents,
Long time no see. What do y’all think about a new video series “I refactor your code”, where I will receive a bunch of Go code from you and make a video on refactoring it?
Let me know your opinions. I think this would be something cool and a learning experience for many people 👊
4 years ago | [YT] | 19
View 5 replies
Steve Hook
Back with another quiz. This time around, let's see what's your experience with Mutex Lock Starvation. Let's imagine both of the snippets below run in their own go routines and they receive the same instance of Mutex. Which snippet will successfully acquire the Mutex Lock more often? 🤔
✅ Snippet A
✅ Snippet B
#code_time #golang #steevehook
4 years ago | [YT] | 15
View 4 replies
Load more