C++23 std::expected

https://www.cppstories.com/2024/expected-cpp23/

#Programming
#cpp

این سایت cppstories کلا خیلی خوبه برای مدرن سی پلاس پلاس

چند الگوریتم مفید در c++

1) std::min_element
با این الگوریتم میتونین کوچیک ترین عضو یه کانتینر رو پیدا کنین
و البته برای مقایسه المنتای کانتینر میتونین یه لامبدا بهش پاس بدین:

std::vector<double> vec;
double min=*std::min_element(vec.cbegin(), vec.cend());

std::vector<MyType> vec2;
MyType min = *std::min_element(vec2.cbegin(), vec2.cend(), [](const MyType& lhs, const MyType& rhs){ return lhs.field1<rhs.field1;});

توجه کنید که این تابع ایترتور برمی‌گردونه و برای همینه که از * استفاده شده.

2) std::max_element
مثل الگوریتم قبلی با این تفاوت که ماکسیمم برمی‌گردونه

3) std::minmax_element
این الگوریتم هردوی مینیمم و ماکسیمم رو با یه std::pair از ایترتورها برمی‌گردونه.

4) std::rotate
این الگوریتم کانتینر اعضای کانتینر رو به یه نحو خاصی جابجا میکنه

ورودی تابع سه تا فوروارد ایترتوره. مثلا
std::rotate(vec.begin(), vec.begin()+3 , vec.end());

با صدا زدن اینجوری این الگوریتم روی کانتینر vec، هرچی المنت قبل vec.begin()+3 باشه میره آخر کانتینر و نتیجتا vec.begin()+3 میشه سر کانتینر جدیدمون.
پس اعضای قبل پارامتر دوم این الگوریتم به آخر الگوریتم منتقل میشن تا این پارامتر بشه اول کانتینرمون

4) std::partition
این الگوریتم دوتا ایترتور برای اول و آخر کانتینرمون میگیره و یه لامبدا یا فانکشن پوینتر که boolean برمی‌گردونه و اعضای کانتینر رو جوری می‌چینه که اون اعضایی تابع براشون true هست میان اول کانتینر و اونایی که false ان میرن آخر کانتینر. البته ترتیب اعضا ممکنه بهم بخوره. مثلا فرض کنین یه وکتور از بولینها مثل زیر داشته باشیم:
0,1,0,1,1
و تابع ورودی به فانکشنمون هم صرفا ترو یا فالس این بولین رو برگردونه. نتیجش این میشه که بعد از اجرای الگوریتم، وکتورمون به شکل زیر تبدیل میشه:
1,1,1,0,0

حالا مشکلی که داره اینه که ممکنه ترتیب المنتها حفظ نشه و خب اگه خواسته باشیم که حتما ترتیب حفظ بشه الگوریتم std::stable_partition رو باید استفاده کنیم.

#Programming
#cpp

ویدیوی زیر با یه مثال عملی این الگوریتم‌ها و بعضا ورژن range شون رو هم کامل‌تر توضیح میده:

https://youtu.be/eJCA2fynzME

🔍 قابل توجه علاقه‌مندان به امنیت سیستم‌عامل و توسعه اکسپلویت در لینوکس

من همیشه به تدریس علاقه‌مند بوده‌ام؛ نه صرفاً آموزش تئوری، بلکه انتقال واقعی تجربه‌ها و درک عمیق مفاهیم فنی. از سال‌ها پیش، تمرکزم روی internal سیستم‌عامل‌ها—به‌ویژه ویندوز و لینوکس—و مباحث امنیتی بوده و سعی کرده‌ام این مطالب تخصصی را به زبانی ساده، کاربردی و قابل‌فهم برای دیگران ارائه دهم.

🎓 حالا نوبت یک قدم جدید و متفاوت رسیده:
«دوره‌ی Exploit Development در لینوکس»
از تحلیل آسیب‌پذیری‌ واقعی گرفته تا نوشتن اکسپلویت‌های عملی و کاربردی.

اما تصمیم گرفتم یک شرط خاص برای انتشار این دوره بگذارم:
🎯 اگر اعضای کانالم به ۵۰۰۰ نفر برسند، دوره را به صورت کامل و رایگان منتشر می‌کنم.

بیش از ۲۰ ساعت ویدئو و تمرین عملی بدون تبلیغات، بدون پرداخت هزینه—صرفاً برای این‌که دانش تخصصی، راحت‌تر و بی‌واسطه به دست کسانی برسه که واقعاً به یادگیری اهمیت می‌دن.

🧠 اگر شما هم به این مسیر علاقه‌مندید یا فکر می‌کنید افراد دیگری در اطرافتان هستند که این محتوا به دردشان می‌خورد، خوشحال می‌شم با معرفی کانالم به دوستان‌تان از این پروژه حمایت کنید.

📎 لینک کانال:
https://t.iss.one/OxAA55

✍️راستی سرفصل دوره رو هم می‌تونید در لینک زیر مشاهده کنید:
https://t.iss.one/OxAA55/140

کمی اترنت

اترنت اولین بار دوروبر سالای ۱۹۷۵ توسط Xerox توسعه پیدا کرد که به این ورژنش الان Ethernet I میگن و دیگه استفاده هم نمیشه ولی پایهٔ ورژنای بعدیه

چهار پنج سال بعد و حول و حوش سالای ۱۹۸۰ اینتل و یکی دوتا شرکت دیگه از جمله همین Xerox یه مقدار استانداردترش کردن و Ethernet II رو ارائه دادن که الان خیلی استفاده میشه. سرعت اترنت تو این نسخه 10Mbps عه.

و نهایتا بعد یکی دوسال جناب IEEE اترنت رو به عنوان IEEE 802.3 یه مقدار تغییر داد و ثبت کرد.

امروز روز ما بیش تر از Ethernet II استفاده می‌کنیم ولی 802.3 هم استفادش زیاده.

یه سری اکستنشن داشت 802.3 که سرعت رو افزایش داد:
802.3u -> 100Mbps
802.3ab -> copper 1Gbps
802.3z -> fiber 1Gbps
802.3ae -> 10Gbps
...

کدینگ ورژن 10mbps اترنت، Manchester Phase Encoding یا MPE بود. توی این روش کدینگ، به ازای سطح منطقی یک، یه لبه پایین رونده (از حدود ۰.۹ ولت مثبت به منفی) و برای سطح منطقی صفر، یه لبه بالارونده ارسال میشه و اگه خط صفر ولت باشه، معنیش اینه که خط توی حالت idle عه.
توی ورژنای بعدی البته این کدینگ عوض شده. مثلا توی 1Gpbs کدینگمون 4D pam عه. یعنی چهار خط Pam موازی🤯
تو لینک این پست اطلاعات بیش‌تری درمورد کدینگای مختلف اترنت پیدا می‌کنین:
https://t.iss.one/stuff_for_geeks/979


درمورد فرمت فریم اترنت بخوام بگم اینجوریه که اول هفت بایت preamble داریم. درواقع هفت بار یه عدد ثابت(0xAA) رو می‌فرستیم و بعد یه بایت SFD یا start frame delimiter می‌فرستیم که این هم یه عدد ثابته(0xAB).

هدف از فرستادن این هشت بایت صرفا سینک شدن فرستنده و گیرندست و هیچ کاربرد دیگه‌ای نداره و تو همون کارت شبکه استفاده میشه و به بیرون ازش نمیاد کلا.(نمیشه با کارت شبکه‌های عادی کپچرش کرد. لااقل تا جایی که من سرچ کردم)

اما بعد این هشت بایت اصل ماجرا شروع میشه. بعد این هشت بایت، شیش بایت dst address و بعد شیش بایت src address رو داریم که همون مک آدرس مقصد و مبدأمونه.

بعد از این آدرس‌ها یه دوبایت داریم که توی Ethernet II بهش فیلد type میگن و توی 802.3 فیلد length. توی اترنت ورژن دو این دوبایت نشون دهنده اینن که دیتای PDU ای که در ادامه خواهد بود، چه مدلیه. مثلا برای IPv4، این دوبایت میشن 0x8000 و برای IPv6 میشن 0x86DD و برای ARP میشن 0x0806.

بعد این دوبایت ممکنه دوبایت P/Q tag داشته باشیم و ممکنه هم نداشته باشیم. مثلا اگه دوبایتمون 0x8100 باشن، معنیش اینه که این فریم یه Q tagged frame عه و دوبایت Q tag خواهیم داشت.(این قسمت رو ChatGPT با یه مقدار تفاوت گفت و خب ممکنه عوض شده باشه نسبت به چیزی که من خوندم. اگه می‌دونین بگین تا منم از گمراهی بیام بیرون)

در ادامه ممکنه یه سری تگ دیگه هم باشه یا نباشه و بعدش پیلود لایه بالاتر رو داریم که میتونه تا ۲۰۰۰ بایت باشه.
نهایتا هم یدونه CRC32 داریم برای integrity check تا ببینیم دیتا درست منتقل شده یا نه.

پست بعدی یه عکس میذارم از فرمت فریم اترنت

اون قسمتی که گفتم چت جی‌پی‌تی یه چیز دیگه میگه محل قرار گرفتن 802.1Q header بود که توی این عکس که از ویکی‌پدیاست هم با عکس قبلی فرق داره

یه سوال دیگه اینجا مطرح میشه که CRC32 چیه و چطوری حساب میشه

خب این مدل فیلدها برای تشخیص خطا بکار میرن مثل هش که برای اینکه بفهمیم یه دیتایی درست جابجا شده یا نه
یعنی کاربردشون صرفا integrity checking عه

البته هش خیلی روش بهتری و دقیق‌تریه به نسبت CRC ولی خب اینم یه چیزه کار راه بندازه

برای محاسبه CRCn یه پیام، به یه عدد موسوم به چندجمله‌ای مولد (generator polynomial) نیاز داریم که طولش n+1 عه و الگوریتم محاسبش هم اینه:
به انتهای پیام به تعداد n صفر اضافه می‌کنیم و باقی مانده این عدد جدید رو به چند جمله‌ای مولدمون می‌گیریم. نهایتا مکمل یک این باقی‌مانده میشه CRCn ما.
مکمل یک هم اینه که همه بیت‌ها رو برعکس کنیم(صفرها رو یک و یک‌ها رو صفر کنیم).

خب مشخصه که چون داریم صرفا باقی‌مانده می‌گیریم، مثل هش یه تابع یک به یک نداریم و به همین دلیله که این روش عالی نیست هرچند که چون طول چندجمله‌ای مولدمون سی و دو بیته، با انتخاب بهینش واقعا نتایج خوبی می‌گیریم.


توی اترنت فریم فیلد آخرمون CRC32 کل فریم اترنت به جز منطقا خودشه یعنی از src address تا آخر پیلود.

فک کنم واضحه که گیرنده که فریم اترنت رو میگیره دوباره CRC رو حساب می‌کنه و اگه با CRC موجود توی فریم دریافتیش یکی نبود، می‌فهمه که اشتباه پیام رو گرفته.

اترنت و شبکه محلی مجازی(VLAN)
همونطور که احتمالا می‌دونید، یه مفهومی به اسم لن مجازی یا 802.1q داریم که به ما اجازه میده توی سوئیچ‌هامون شبکمون رو قسمت بندی کنیم بدون اینکه فیزیکی شبکه رو جدا جدا کنیم. توی این پست میخوام درمورد اینکه چجوری این قابلیت تو سطح اترنت رخ میده صحبت کنم.

خب شما توی کنسول سوئیچ وارد میشید و تعریف میکنید که فلان پورت‌ها با هم یه لن مجازی تشکیل بدن.

تو این سناریو هاست ها یا station ها هیچ تغییری نکردن پس فریم اترنتی که از سمتشون میاد هم هیچ تغییری نخواهد کرد و مثل همون چیزی خواهد بود که توی پست‌های قبل‌تر گفتیم.
درواقع یه station فریمش رو می‌فرسته و سوئیچ که می‌دونه از کدوم پورت این فریم واردش شده، طبق جداول vlanای که داره تصمیم می‌گیره این فریم رو به کجا بفرسته اما اینجا یه نکته هست که باعث شد 802.1q بوجود بیاد.
فرض کنید لن مجازیمون فقط به یک سوئیچ محدود نباشه و مثلا بین دو یا چندتا سوئیچ پخش شده باشه.

اینجا باید فریمی که بین سوئیچ‌ها منتقل میشه مشخص باشه مال کدوم لن مجازیه. یعنی نمیشه شما یه فریم مال vlan1 داشته باشی و موقعی که داری میفرستیش برای سوئیچ دومت نگی این مال کدوم vlanعه. خب واضحه که نمیشه.

برای همین به فریم اترنتمون یه تگ اضافه می‌کنیم به اسم تگ 802.1q که دقیقا توش مشخص کردیم این فریم مال کدوم vlanعه. این تگ بعدا قبل اینکه برسه به استیشن مقصد توسط سوئیچ پاک میشه.
به این کار که ترافیک چند vlan رو از یه کانال عبور بدیم، trunking هم میگن(شاید مفهوم دقیق تری داشته باشه ولی من همینقدر می‌دونم)

البته باید سوئیچ کانفیگ بشه و براش تعریف بشه که کدوم پورتش به یه سوئیچ دیگه داره وصل میشه و برای این پورتش trunking ست بشه.

همونطور که توی عکسای قبلی مشخصه، به فریممون یه p/q tag اضافه میشه که یکی از بخشاش دوازده بیت VIDعه که نشون میده می‌تونیم تا 2^12 یا 4096 تا vlan تعریف کنیم(البته VID نمیتونه صفر و 4095 باشه که دوتا از مجموع تعداد vlan های قابل تعریف کم میکنه)

توی هدر 802.1q یه سه تا بیت بعد از tag id داریم که بهش priority code pin یا PCP هم میگن و این قسمت میشه بخش 802.1p مون. این سه تا بیت طبق استاندارد مشخص کننده اینن که این فریم چقدر اولویت داره و آیا باید زودتر از بقیه فریم‌ها منتقل بشه یا نه.

البته اینکه هر مقدار مشخص از این سه بیت چه معنایی بده رو استاندارد تعریف نمیکنه و دست سازنده‌ها رو باز می‌ذاره. مثلا رایجه که برای VoIP که لیتنسی کم مدنظره، این مقدار PCP عدد شیش باشه.

پ.ن: سورس این چند پست اخیر کتابیه که 2011 چاپ شده و ممکنه یه مقدار استانداردا عوض شده باشن.

پ.ن۲: شبکه رو تازه شروع کردم و ممکنه اشتباه داشته باشه توضیحاتم

اترنت و MTU

اگه یبار دیگه به فریم اترنت نگاه کنیم، می‌بینیم که یه بخشی به اسم پیلود داریم. این بخش میتونه از ۴۶ بایت تا ۱۵۰۰ بایت یا جدیدا ۲۰۰۰ بایت توی نسخه‌ی استاندارد اترنت باشه. یه اکستنشن اترنتی به اسم jumbo frame هم داریم که اجازه میده تا ۹۰۰۰ و خورده‌ای بایت برسیم. به این سایز MTU یا Maximum Transmission Unit گفته میشه.

کم بودن MTU باعث میشه زیادی CRC بگیریم و چک کنیم که خب خوب نیست ولی زیاد بزرگ بودنش هم باعث میشه اگه فریم خراب بشه، یه حجم بزرگی از دیتا دوباره ارسال شه که بازم خوب نیست.

توی گنوم می‌تونین دستی mtu اینترفیستون رو تنظیم کنین و خب با nmcli و iproute هم قاعدتا میشه. مثلا با iproute داریم:
ip link set dev eth0 mtu 9000

پ.ن: یه extreme jumbo frame هم داریم که اجازه میده mtu بزرگتر از این حرفا باشه ولی NIC های خاص می‌خواد

Linux Device Tree

https://youtu.be/Nz6aBffv-Ek

اینو یادم رفت بگم که فریم وقتی به station میرسه یا ازش خارج میشه هیچ 802.1p/q تگی نداره و فقط بین سوئیچ‌هاست این موضوع.

یه سوئیچ به فریمی که از station می‌گیره اینو اضافه می‌کنه و یه سوئیچ که به station تحویل میده پاکش می‌کنه

اترنت و auto negotation

خب فرض کنید که سیستمون رو به یه سوئیچ وصل می‌کنین.
می‌بینین که بدون هیچ کار اضافه‌ای، سوئیچ و سیستمتون اترنت هم رو می‌شناسن و با هم ارتباط می‌گیرن ولی خب اگه مثلا به پورت سریال کار کرده باشین می‌دونین که برای هر پروتکلی تنظیمات زیادی وجود داره مثلا توی سریال baud rate داریم، parity bit داریم، طول خود پکتای سریالمون هست و...

اترنت هم قاعدتا از این قاعده مستثنی نیست و خب نسبت به سریال پروتکل خیلی پیچیده‌تریه و قاعدتا باید تنظیمات لایه فیزیکی زیادی داشته باشه و خب سوال اینه چجوری دوتا nic با هم ست می‌شن و می‌تونن بدون هیچ تنظیمی ارتباط بگیرن.

جواب auto negotiation عه. پروتکلی که تو لایه فیزیکی(قبل Ethernet یا بخش فیزیکی اترنت هم میگن بهش) قرار داره و به کمک اون لینک‌ها از اطلاعات هم دیگه مطلع میشن و تصمیم می‌گیرن چجوری با هم کار کنن.

مثلا اترنت اون اوایل که فقط یه لینک فیزیکی وجود داشت و همه سیستم‌ها به اون لینک متصل میشدن، half duplex بوده و دوتا سیستم همزمان نمیتونستن رو لینک فیزیکی دیتا بفرستن و بگیرن اما امروزه که سوئیچ‌ها رو داریم و کابل‌کشی عوض شده تقریبا همه‌جا ارتباط full duplex داریم.
این یکی از مواردیه که توی auto negotiation بین stationها منتقل میشه و تصمیم‌گیری میشه که کدوم یکی استفاده شه.

یا مثلا سرعت لینک
فرض کنین یه nic تا 2.5GB سرعت می‌تونه داشته باشه ولی یکی تا 100MB. خب اینجا طرفین به هم اطلاع میدن و سرعت لینک پایین‌تر انتخاب میشه

میشه با ethtool توی لینوکس دید که پورتای اترنتتون چه تنظیماتی دارن و این مورد براشون فعال هست یا نیست و میشه این مورد رو غیرفعال هم کرد ولی غیرفعال کردنش اصلا توصیه نمیشه. دلیلش هم اینه که اگه یه طرف کارت شبکه قدیمی داشته باشیم که فقط half duplex بتونه کار کنه و یه طرف دیگه full duplex باشه، بشدت افت سرعت خواهیم داشت.
پس توصیه میشه که این گزینه رو همیشه روشن نگه دارین مگر در شرایطی که خب مطمئنین باید خاموش باشه

اترنت و STP

یکی دیگه از مشکلاتی که داریم مخصوصا وقتی تو شبکه بیش‌تر از یک سوئیچ وجود داره، اینه که ممکنه لوپ توی شبکه درست شه. یعنی بیش‌تر از یک مسیر برای وصل کردن دوتا سیستم به هم وجود داشته باشه.

این قضیه مشکل سازه چون اینکه چه سیستمی(چه مک آدرسی) به چه پورتی از یه سوئیچ وصله توی سوئیچ ذخیره میشه(forwarding table میگن بهش) و خب وقتی بیش‌تر از یک مسیر باشه، سوئیچ ممکنه گیج بشه و مدام این جدولش عوض شه که خوب نیست. یا برای فرستادن broadcast frame ها، اگه حلقه داشته باشیم، فریممون میوفته تو حلقه و خب اینجوری تا ابد بین سوئیچ‌ها می‌چرخه که اصلا خوب نیست.

راه حل چیه؟
اینه که گراف شبکمون، بدون دور باشه و برای وصل کردن هر دوتا نود، فقط یه مسیر داشته باشیم.
پروتکل STP کارش همینه و درواقع با غیرفعال کردن یه سری پورت‌های سوئیچ، این قضیه رو خودبخود رفعش می‌کنه.
البته STP سال 1990 اومد و خب یه‌سری مشکلات داشت و به همین دلیل جایگزینش که RSTP باشه، سال 2001 اومده.

پروتکل‌های STP و RSTP با فریم‌هایی به اسم BPDU یا bridge protocl data unit برای ارتباط بین سوئیچ‌ها استفاده می‌کنن.

بذارید یکم ریزتر و دقیق‌تر STP رو بررسی کنیم. این پروتکل اینجوری کار می‌کنه که برای پورت‌های سوئیچ یه state machine تعریف می‌کنه و خب قاعدتا یه سری state.
مثلا میگه وقتی سوئیچ روشن شد، همه پورتا میرن روی حالت blocking البته بجز پورتایی که دستی و توسط ادمین غیرفعال تعریف شدن.
توی حالت بلاکینگ پورت فقط می‌تونه BPDU ها رو ببینه و اگه دید طبق BPDUی ورودی قراره توی یه مسیری باشه، از blocking میره به مد listening. توی این مد، پورت می‌تونه علاوه بر شنیدن bpduها، اونا رو ارسال هم بکنه ولی هیچ کار دیگه‌ای نمی‌تونه انجام بده.
نهایتا پورتی که توی listening مد هست، بعد یه مدت زمان مشخصی(۱۵ ثانیه) میره به حالت learning و توی این حالت پورت تنها کاری که نمی‌تونه بکنه، ارسال و دریافت فریم‌های دیتاست(می‌تونه bpdu بفرسته و بگیره و میتونه forwarding table رو پر کنه ولی نمی‌تونه فریم‌های دیتایی که بین stationها جابجا میشن رو بفرسته یا بگیره).
بعد از این مد هم، با یه تاخیر بیست ثانیه پورت میره توی حالت forwarding که دیگه میتونه هرکاری انجام بده.

مشکلی که STP داره همینه که تاخیر زیادی داریم و حداقل چهل پنجاه ثانیه تاخیر لازمه تا یه پورت بره توی حالت عادی. RSTP که مخفف rapid stpعه دقیقا این مشکل رو حل می‌کنه و تاخیر پورت‌ها رو نهایتا به یکی دوثانیه میرسونه که خب خیلی خوبه

A guide to SDR and DSP using Python
https://pysdr.org/content/intro.html

#sdr

خیلی آموزش خوبیه
مثلا موارد زیر جزو چیزایی که یاد میده
Sampling basics
IQ Sampling
FFT
Complex numbers
Signal Power and Power Spectral Density
Digital Modulations (ASK, PSK, FSK, QAM)
AWGN, SNR, SINR, Noise, Gaussian Noise
Filtering, FIR, IIR
Pulse Shaping
Channel Coding
Beamforming and DOA
...

📢 انتشار فصل اول دوره توسعه اکسپلویت در لینوکس

📚 این فصل شامل ۷ ویدئو می‌باشد و در آن با مفاهیم بنیادین اجرای برنامه‌ها در سیستم‌عامل لینوکس آشنا می‌شوید؛ از مروری بر برنامه‌نویسی و ساختار فایل‌های اجرایی گرفته تا نحوه‌ی ایجاد و اجرای پروسه‌ها و مدیریت حافظه. این فصل پایه‌ای محکم برای درک مباحث پیشرفته‌تری ایجاد می‌کند که در فصل‌های آینده به آن‌ها خواهیم پرداخت.

✍️ لینک ویدئوهای فصل در یوتیوب:
00) Course Introduction
P01-01) Programming Review
P01-02) ELF Intro
P01-03) Process Execution
P01-04) Heap Investigation
P01-05) Process Address Space
P01-06) Virtual Memory
P01-07) Syscalls Intro

✍️ لینک ویدئوهای فصل در آپارات:
https://aparat.com/v/qxvin87
https://aparat.com/v/fwd0751
https://aparat.com/v/ljqz0v8
https://aparat.com/v/pdw1xkk
https://aparat.com/v/nct8m83
https://aparat.com/v/eak4pvp
https://aparat.com/v/lbuc0q0
https://aparat.com/v/sfb8398

#linux #exploitdev #internals #programming #security

glibc
این کلمهٔ پنج حرفی خیلی حرف برای گفتن داره
خیلیییی

ببینید ما میایم یه کد سی توی لینوکس می‌نویسیم. مثلا کد hello world با استفاده از تابع printf
این برنامه رو که کامپایل می‌کنیم، اگه ldd بگیریم ازش خواهیم دید که به glibc لینک شده. برنامه‌ای که چهار خطه مجموعا، دیپندسی glibc داره و خب این خودش نشون‌دهندهٔ اهمیت glibcعه.

اما ایشون چیکار میکنه؟
خیلی کارها که یه سریاشو هنوز مطمئنم نمی‌دونم. ولی اگه بخواید glibc رو حذف کنید، خیلی همه چی سخت خواهد شد. مثلا شما تنها راه ارتباط با کرنلتون صدا زدن مستقیم سیستم‌کال‌ها با شمارشون خواهد بود.
یعنی اگه بخواین حتی یه متن چاپ کنین، باید سیستم‌کال write رو صدا بزنین اونم نه با تابع write چون خود این تابع عضوی از glibcعه بلکه با کد اسمبلی!

پس اهمیت ایشون خیلی زیاده
یکی دیگه از کارایی که انجام میده، اینه که تابع main برنامه ها رو ایشون صدا می‌زنه!
درواقع اگه شما توی یه برنامه ای از glibc استفاده نکنین، لزومی نخواهد داشت که تابع main داشته باشین (استفاده هم بکنین لزومی نداره البته) چون این تابع رو کرنل موقع اجرای برنامه صدا نمیزنه بلکه glibc runtime صداش میزنه.

کرنل فقط یه فایل ELF می‌بینه که یه entry point داره و برنامه رو از اون نقطه اجرا می‌کنه. هیچ اصراری هم بر اسم main نداره.

یکی دیگه از کارای وحشتناک حیاتی جناب glibc، لودر پویا یا dynamic loader ایشونه. کرنل لینوکس اصلا dynamic loading نداره😂
پس اگه برناممون دیپندنسی کتابخانه‌ای به چندتا shared library داره، توی ELF فایل مشخص می‌کنه و به کرنل میگه بجای اینکه entry point من رو اجرا کنی، برو فلان interpreter رو اجرا کن که برای برنامه های glibc دار، این اینترپتره میشه ld-linux.so که بخشی از glibc عه و نه کرنل.

پس glibc خیلی نقش حیاتی‌ای داره.

جالبه بدونید که چندتا جایگزین هم داره مثلا musl که یه ورژن سبک‌تر از glibcعه

یا bionic که مال گوگل و اندرویده و کاملا اپن سورسه یا crt و ucrt ویندوز

یه نکته دیگه اینکه اگه بتونین توی libcها باگ پیدا کنین، خیلی باگ خفنی حساب میشه

همزمانی در سی‌پلاس‌پلاس
پست ۶

توی این پست میخوام درمورد deadlock بیش‌تر صحبت کنم.
اصولا deadlock موقعی پیش میاد که به هر دلیل دوتا ترد به شکل دایره وار منتظر همدیگه بمونن. یکی از دلایل این انتظار میتونه میوتکس(میوتک؟)ها و یا درواقع ریسورس‌ها باشن ولی دلایل دیگه مثل طراحی بد هم میتونه باعث انتظار و deadlock بشه.

راه حل چیه؟
اولین و شاید بشه گفت مهم ترین نکته برای رفع deadlock اینه که قاعده زیر رو رعایت کنیم:
همیشه n تا میوتکس رو به یک ترتیب لاک کنید.

اگه این قاعده رعایت شه، از نظر ریسورسی یا همون میوتکسی به مشکلی نمی‌خوریم هرچند که ممکنه طراحیمون هنوز مشکل داشته باشه. دلیل اینکه چرا این روش کار میکنه رو میتونین با کشیدن چیزی به اسم گراف wait-for ببینین.

نکته دومی که میتونه کمک کننده باشه اینه که تا جایی که ممکنه از nested lockها بپرهیزید. این نکته هم میتونه جلوی طراحی‌های مشکل دار رو بگیره.


اما C++ چی در چنته داره؟
خب حداقل دوتا عنصر خوب داریم، کلاس std::scoped_lock که از c++17 پیداش میشه و یک تابع که شاید بشه گفت ورژن قدیمی‌تر این کلاسه، std::lock

اول با std::lock شروع کنیم. کانسپت ساده‌ای داره. این تابع n تا میوتکس رو می‌گیره و به ما قول میده جوری لاکشون کنه که deadlock رخ نده (واقعا نمیدونم چجوری).

و اما std::scoped_lock یه template کلاسه که توی متد سازندش n تا میوتکس رو می‌گیره و جوری لاکشون میکنه که deadlock رخ نده و البته توی دیستراکتورش همه میوتکس‌هایی که بهش داده شده بود رو مثل std::lock_gaurd آنلاک می‌کنه.

به این دلیل این کلاس template classعه که چندین نوع mutex داریم و کلاس انتظار داره تایپ میوتکس‌های ورودی بهش رو بهش بگیم. البته که چون این کلاس توی c++17 اضافه شده و همزمان توی همین ورژن template deduction به استاندارد اضافه شده، میتونین template argument ها رو بهش پاس ندین و بذارین خودش تشخیصشون بده.


توجه کنید که ممکنه لاک کردن میوتکس‌ها با خطا یا exception مواجه بشه که در اینصورت هردوتا عنصر بالا همه میوتکس‌های دیگه‌ای که لاک کردن رو آنلاک می‌کنن و اکسپشن بوجود اومده رو rethrow میکنن.

توی پست بعدی درمورد std::promise و std::future صحبت می‌کنیم.

ادامه

#cpp
#concurrency
#programming