شما به این ویدیو دسترسی ندارید

در این ویدیو با مفاهیم مهمی مثل Race condition, Thread safe, Dead lock آشنا میشوید. مشکل Race condition زمانی اتفاق میفتد که دو یا چند thread بخواهند به صورت همزمان به یک shared resouce دسترسی پیدا کنند. در این حالت ممکن است ترد دوم در حین کار ترد اول به shared resource دسترسی پیدا کند و اطلاعات ناقصی که ترد اول در حال کار روی آنها بود را دریافت کند. برای حل این مشکل باید از کلاس Lock استفاده شود بصورتی که برنامه را با استفاده از متد acquire قفل کرده تا ترد دیگری نتواند به منابع دسترسی داشته باشد و بعد از اتمام کار با متد release برنامه را آزاد کند. در این حالت برنامه thread safe خواهد بود. مشکل dead lock زمانی اتفاق میفتد که به صورت اشتباه برنامه ای که با استفاده از متد acquire قفل شده بود را دوباره با متد acquire قفل کنیم. در این حالت برنامه block شده و نه پاسخی برگشت داده میشود و نه برنامه تمام میشود. برای حل این مشکل پیشنهاد میشود که lock را به صورت یک context manager با متد with استفاده کنید.



0

intro

14:41

رایگان

1

creating threads

10:14

رایگان

2

Thread subclass

5:40

3

daemon

6:52

4

current_thread, enumerate

7:15

5

ThreadPoolExecuter

5:56

6

Lock

14:52

7

RLock

4:16

8

Semaphore

9:55

9

Timer

1:40

10

Event

10:15

11

done

1:12

رایگان

دوره های پیشنهادی

آموزش پروژه محور جنگو - ساخت شبکه اجتماعی
آموزش پروژه محور جنگو - ساخت شبکه اجتماعی
تکمیل ضبط
امیرحسین بیگدلو
8:37:13 229 هزارتومان
دوره آموزش RabbitMQ
دوره آموزش RabbitMQ
تکمیل ضبط
امیرحسین بیگدلو
4:16:33 229 هزارتومان
دوره آموزش FastAPI
دوره آموزش FastAPI
تکمیل ضبط
امیرحسین بیگدلو
2:39:08 0 هزارتومان



ارسال نظر


میلاد

2 سال قبل پاسخ به نظر

سلام.
یه سوالیذهنم را درگیر کرده:
مگه مفهوم lock جدای از زبان برنامه نویسی مربوط به این نمیشه که
دو یا چند ترد به شکل همزمان روی یه منبع مشترک کار کنند و این باعث تداخل و خطای برنامه بشه.

خوب در این صورت زبان پایتون که parallel نیست بلکه cuncurrent و هیچ دو تردی دقیقا همزمان باهم فعال نمیشه و سویچ ترد اتفاق می افتد و توی این حالت و این مثال :
ترد 1 فرضا 1000 تا زیاد میکه بعد سویچ میکنه روی ترد2 و 7000 تا کم میکنه و در نهایت عدد به صفر می رسه.

وهیچ وقت مشکل منبع مشترک پیش نمیاد.

ارسال نظر



امیرحسین بیگدلو

2 سال قبل

سلام
خیر. کاملا برعکس همه چیز رو متوجه شدید.

Ali

2 سال قبل پاسخ به نظر

سلام و خسته نباشید. تو این مثال اگه ما از threading استفاده نمیکردیم؛ قطعا برای موضوع race condition جای بحثی نمی موند. ولی خب مثال هست و هدف ما درک race condition. ولی باز یک چیزی ذهن منو مشغول کرده. تو تابع add و subtract ما اصلا وقفه ای نخواهیم داشت. یک ریز به مقدار num اضافه میکنه و هیچ وقفه ای این وسط نیست؛ نه sleep داریم و نه از کاربر درخواستی. پس وقتی Thread یک رو start میکنیم، انتظار داریم اون Thread تمام و کمال اجرا بشه و num مقدار صد هزار رو بگیره. پس از تمام شدن t1، که ترِد دوم به کار کردن شروع میکنه (به این دلیل که gil اجازه اجرای فقط یک thread در آن واحد رو میده) و دقیقا همون صد هزار تارو کم میکنه تا به صفر برسه. این وسط تو t1 ما وقفه یا sleep ــی نداریم که باعث بشه t2 اجرا بشه و جهت اینکه تسک اول هنوز کامل انجام نشده مبحث shared resources دردسر ساز بشه. چرا این اتفاق بار اول افتاد ؟ قاعدتا هیچ وقت نباید اتفاق بیفته. (من خودم اجرا کردم همین کد رو و عدد تصادفی چاپ نکرد و درست بود همه چی.)

ارسال نظر



امیرحسین بیگدلو

2 سال قبل

سلام
خب مشخص نیست که در حین کار کردن ترد۱ چه اتفاقی در سیستم عامل افتاده. شاید یک لحظه ارتباط ضعیف شده و ترد۲هم از فرصت استفاده کرده و داخل نتیجه تداخل ایجاد کرده.
همونطوری هم که خودت گفتی این تداخل زیاد اتفاق نمیفته و به همین خاطر هم هست که در اکثر مواقع نتیجه درست نشون داده میشه.

saeedou

3 سال قبل پاسخ به نظر

سلام

1. وقتی از safe threading استفاده میکنیم و لاک میکنیم انگار از thread استفاده نمیکنیم و سرعت بالا نمیره
2.کلا اینجا I/O bound نیست و کلا threading مناسب نیست

آیا برداشتم درسته؟

ارسال نظر



امیرحسین بیگدلو

3 سال قبل

سلام
1. لاک فقط در زمانی که از منابع اشتراکی استفاده میکنیم safe thread هست و در بقیه برنامه سرعت میره بالا
2. خیر، همونطور داخل مثال گیتهاب هم نشون دادم threading کاملا مناسبه

مونگارد