مشکل عجیب با شمارنده

[armintirand]

سلام
من یک شمارنده که قبلا از همین سایت برداشته بودم رو وقتی با apachiوphp اجرا میکنم کار نمیکنه وروی سرور سایتم هم امتحان کردم کار نکرد ولی با برنامه geany وقتی اجراش میکنم کار میکنه.مجوز هاشون رو هم تغییر دادم؟
اینم کد:

<?php



session_start();

$file_name = "conter.txt";    

$file_contents = file_get_contents($file_name) or die("can not open file");

$file= (int) $file_contents ;



    if($_SESSION["user"] == false)

    {

        $file ++;

        file_put_contents($file_name,$file);

        $_SESSION["user"]="true";

    }

    

echo($file);    

?>

[eshpilen]

یه مشکل روی سرورهای GNU/Linux تاجایی که دیدم اینه که وقتی PHP میخواد در دایرکتوری فایل ایجاد کنه (یا در فایلی بنویسه)، مجوز لازم رو بدست نمیاره. البته معلوم نیست این مشکل شما باشه. روی ویندوز کار میکنی یا لینوکس و لوکال یا روی هاست؟
راستی این کانترهای ساده بنظرم مشکل دارن. بنده قبلا تست هم کردم و دیدم که براحتی قاطی میکنن. در شرایط عادی معلوم نمیشه، ولی اگر دوتا یا چند درخواست بصورت همزمان به صفحهء شمارنده ارسال بشه ممکنه درهم تداخل کنن و مشکل پیش بیاد؛ اونم مشکلات اساسی! فرض کن زمانی که یک صفحه داره محتویات فایل رو میخونه، صفحهء دیگر درحال اجرا درحال نوشتن توی همون فایل باشه؛ به اینصورت عدد شما کاملا بهم میریزه. یا موقعی که عدد رو خوندی ولی هنوز مقدار اضافه شده رو در فایل ننوشتی، یک صفحهء دیگه جلوتر مقدار رو افزایش داده و در فایل مینویسه؛ بنابراین وقتی صفحهء شما مقدار رو مینویسه درواقع یک واحد شمارش کاربر از دست میره.
اینا جزییاتی هست که خیلی ها متوجه نیستن و رعایت نمیکنن. برنامه های وب هم در این موارد مثل برنامه های Multi-Thread عمل میکنن و نیاز به متدهای قفل و همزمان سازی و غیره دارن.
البته یک راه هم که بنده شخصا استفاده کردم اینه که مقدار رو توی دیتابیس ذخیره میکنم، نه در فایل. این راه راحتی هست. ولی بنظرم روی سیستم فایل هم میشه براحتی قفل پیاده کرد که حداقل درمورد سایتهای با ترافیک معمولی فکر نمیکنم مشکلی در زمینهء Performance و غیره داشته باشه.

[armintirand]

من رو سیستم خودم لینوکس دارم و روی هاست لینوکس هم سایت رو تست زدم ولی تو هیچ کدوم جواب نگرفتم مجوزها رو هم تنظیم کردم ولی جواب نمیده؟
اگه با دیتابیس بخوام شمارنده بسازم مگه مشکلات همزمان نوشتن و خوندن رو نداره؟ در ضمن باید تو دیتابیس فقط عدد رو بذارم؟

[funpatogh]

یکنمونه با php mysql

[eshpilen]

اگه با دیتابیس بخوام شمارنده بسازم مگه مشکلات همزمان نوشتن و خوندن رو نداره؟ در ضمن باید تو دیتابیس فقط عدد رو بذارم؟

والا الان که گفتی دقیقا مطمئن نیستم؛ خودمم شک کردم
ولی شاید قبلا اینو تست کردم و یادم نیست.
بهرحال دیتابیس حداقل جلوی بعضی خطاهای متداول و مهم رو میگیره، چون خودش مکانیزمهایی برای جلوگیری از دسترسی همزمان و خراب شدن داده ها داره؛ وگرنه هر اطلاعاتی که توی دیتابیس ذخیره میکردید ممکن بود خراب بشه، چون اطلاعات زیادی میتونن بصورت همزمان به دیتابیس برای درج ارسال یا ازش خونده بشن و این یک شرایط عادی برای تمام دیتابیس های استاندارد هست.
بنده بطور مثال از چنین کوئری ای برای درج اطلاعات مختلفی از کلاینت ها در دیتابیس استفاده میکنم:

$query="insert into `{$table_names[0][1]}` values(NULL, $raddr,  $userAgent, $time, $hostRequested, $rport, $scrRes, $referer)";

بعد با شمردن تعداد رکوردهای موجود در جدول با کوئری ای مثل select count(no) as num from `{$table_names[0][1]}` هم میشه تعداد بازدید کننده ها رو شمرد (فیلد اول یک فیلد autoincrement بنام no هست).
خب حداقل امنیتی که کوئری درج اطلاعات به ما میده اینه که امکان نداره دو دستور درج (INSERT) مختلف با هم تداخل کنن. ولی در روشی که شما با فایل کار میکنید، این امکان وجود داره که دو برنامه بصورت همزمان توی فایل در نقاطی بنویسن که باعث قاطی شدن اطلاعات هردو بشه.
حالا چه حالت دیگری باقی میمونه؟
اینکه کوئری درج ما اگر قبل از اینکه موفق بشه اطلاعات رو در دیتابیس ثبت بکنه، اگر یک اسکریپت PHP دیگر هم اجرا بشه و کوئری درج دیگری رو به دیتابیس بفرسته چی میشه؟
خب در اینجا هم فکر نمیکنم هیچ مشکلی پیش بیاد، حتی اگر کوئری دوم زودتر از کوئری قبلی موفق به درج اطلاعات در دیتابیس بشه (با اینکه بنظرم یا امکان نداره یا احتمالش خیلی کمه)؛ یعنی در هر صورت هر دو کوئری موفق به درج اطلاعات در دیتابیس خواهند شد و بنابراین هر دو بازدید کننده در نهایت شمرده میشن؛ فقط در دسترسی هایی که در همون زمان برای خواندن تعداد رکوردها جهت نمایش مقدار شمارنده در صفحه صورت میگیره، این امکان وجود داره که تعداد معدودی از بازدید کننده ها بحساب نیان (چون ممکنه MySQL هنوز اجرای چند کوئری INSERT رو تموم نکرده باشه) که اینم بنظرم در شرایط عادی نادر هست و تعدادش نهایتا از یکی دوتا بالاتر نمیره (مگر در شرایط ترافیک بسیار سنگین و بازدید کننده های جدید همزمان زیاد)، و در نهایت برای شمارش های بعدی این تعداد هم اضافه خواهند شد و شمارش هیچ کاربری جز برای مدت و تعداد بسیار محدودی از نمایش شمارنده از دست نخواهد رفت.
خب بنظرم روشن شد که این روش بقدر کافی ایمن و دقیق هست!
ولی روشی که فقط یک عدد رو در دیتابیس درج کنید و همون رو افزایش بدید بنظرم جای تحلیل بیشتری داره و باید با طرز کار DBMS بیشتر آشنا باشیم و شاید تنظیمات خاصی باید انجام بدیم (مثلا اعمال Lock). فکر میکنم اگر از روشی که بنده بکار گرفتم استفاده کنید، خیلی بهتر هست و این ریسک از بین میره و حتی کارایی هم میتونه بالاتر بره (چون در شرایط ترافیک سنگین، کوئری های دیگه لزوما مجبور نیستن بخاطر یک کوئری دیگه صبر کنن). یعنی به ازای هر کاربر یک رکورد در جدول مخصوص شمارنده درج کنید (شامل هر اطلاعاتی که میخواید ذخیره بشه که میتونه فقط درج یک رکورد با یک فیلد فاقد اطلاعات خاصی هم باشه). بعد برای گرفتن تعداد بازدیدکننده ها کافیه تعداد رکوردهای موجود در جدول رو بشمارید.

[eshpilen]

یکنمونه با php mysql

بنظرم این اسکریپتی که شما معرفی کردید هم از افزایش مقدار یک فیلد خاص در جدول استفاده میکنه و بنابراین ابهام یا اشکالی که ذکر کردم بهش وارد هست. خب اون ابهام چیه؟ اینکه، فرض کنید دو صفحه بصورت (تقریبا) همزمان مقدار فیلد شمارنده رو میخونن، مثلا هردو مقدار 121 رو میخونن، بعد هرکدام از صفحات مقدار 121 رو یکی اضافه میکنن که میشه 122، و بعد هر دو کوئری آپدیت رو اجرا میکنن که باعث میشه عدد 122 در فیلد شمارنده درج بشه (فرقی نمیکنه که کدام کوئری آپدیت اول اجرا بشه)، درحالیکه ما دو بازدید داشتیم و عدد باید دوتا اضافه میشده؛ یعنی 123.
ضمنا صفحات همزمان عملا میتونن هر تعدادی باشن. ذکر دوتا بخاطر سادگی مثال بود.
البته ممکنه در عمل امکان این تداخل ها خیلی کم باشه، ولی از نظر تئوریک امکان دارن و این به عهدهء برنامه نویس هست که در اینمورد آگاه باشه و تدابیر لازم رو بکار ببره. در شرایط خاص و جدی تر، این موارد میتونن آشکار و مشکل ساز بشن.
روشی که بنده گفتم به ازای هر کاربر یک رکورد در دیتابیس درج کنیم امکان اینطور تداخل ها رو اصلا نداره.

[armintirand]

کل حرفای شما درست ولی من الان دارم میگم مشکل کد من چیه؟ یعنی چرا اصلا کار نمیکنه؟

[Keramatifar]

شما باید ببینید که آپاچی Access نوشتن در فولدر مربوطه را دارد یا نه
دستور chmod a+w را در آپاچی اجرا کنید تا مطمئن شوید دسترسی read/write به فولدر مربوطه وجود دارد
مثلا:
chmod a+w YourProgramFolder/YourFileFolder

[armintirand]

دوست عزیز من مجوزها رو به این صورت دادم ۷۷۵ برای فایل php و۷۷۷ برای فایل شمارنده آیا این با اونی که شما میگید فرق داره؟ مگه به خود برنامه آپاچی هم باید مجوز بدیم؟

[arturmacnight]

بهتره از این روش استفاده کنید تا جواب بگرید:

<?php



        $liner=file('counter.txt'); //ba in kole file ro tu array liner mirizim

        $outtext=$liner[0]+1; // khate 1 ro ke man adad farz kardam ba 1 add mikonim

        file_put_contents('counter.txt',$outtext); //adade jam shode ro tuye file save mikonim



?>

[armintirand]

ممنون این روش کار میکنه ولی من هنوز ندونستم ایراد اسکریپت خودم چیه؟

[eshpilen]

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

[shahriyar3]

بنظرم این اسکریپتی که شما معرفی کردید هم از افزایش مقدار یک فیلد خاص در جدول استفاده میکنه و بنابراین ابهام یا اشکالی که ذکر کردم بهش وارد هست. خب اون ابهام چیه؟ اینکه، فرض کنید دو صفحه بصورت (تقریبا) همزمان مقدار فیلد شمارنده رو میخونن، مثلا هردو مقدار 121 رو میخونن، بعد هرکدام از صفحات مقدار 121 رو یکی اضافه میکنن که میشه 122، و بعد هر دو کوئری آپدیت رو اجرا میکنن که باعث میشه عدد 122 در فیلد شمارنده درج بشه (فرقی نمیکنه که کدام کوئری آپدیت اول اجرا بشه)، درحالیکه ما دو بازدید داشتیم و عدد باید دوتا اضافه میشده؛ یعنی 123.
ضمنا صفحات همزمان عملا میتونن هر تعدادی باشن. ذکر دوتا بخاطر سادگی مثال بود.
البته ممکنه در عمل امکان این تداخل ها خیلی کم باشه، ولی از نظر تئوریک امکان دارن و این به عهدهء برنامه نویس هست که در اینمورد آگاه باشه و تدابیر لازم رو بکار ببره. در شرایط خاص و جدی تر، این موارد میتونن آشکار و مشکل ساز بشن.
روشی که بنده گفتم به ازای هر کاربر یک رکورد در دیتابیس درج کنیم امکان اینطور تداخل ها رو اصلا نداره.

این مثالی که میزنید درست نیست
اجرای دستور ساده آپدیت در دیتابیس زمانی معادل (9 total, Query took 0.0003 sec) رو میگیره
خیلی سادست که لودینگ صفحه برای هر کاربر فرق میکنه بنابر این سرعت اجرای اسکریپت هم فرق میکنه و سرعت دستور آپدیت mysql هم فرق میکنه
این مثال شما خیلی دور از ذهن بود و به هیچ وجه قانع کننده به نظر نمیرسه. این اسکریپتی که محمد گذاشته به درستی کار میکنه بدون خطا در محاسبات.

[eshpilen]

اون اسکریپت و الگوریتم های مشابه ظاهرا درست کار میکنن، ولی اصولی نیستن. یعنی بر اساس تصادف و احتمال درست کار میکنه، درحالیکه میشد طوری طراحیش کرد که بر شانس و احتمالات استوار نباشه.
چنین ضعفهایی در برنامه نویسی، درواقع باگ محسوب میشن (۱۰۰٪).
در برنامه نویسی چند نخی تمام این اصول باید رعایت بشن. بله در خیلی موارد و در شرایط عادی ممکنه برنامهء شما با مشکل مواجه نشه یا حتی اگر مشکلی بوجود بیاد زیاد مهم نباشه (مثلا از دست رفتن آمار تعداد معدودی کاربر در نهایت)، ولی فرق یک الگوریتم حرفه ای که میتونه برای هر کار جدی/دقیق/سنگین و دارای نیاز به امنیت بالا در محدودهء وسیعی از شرایط کار کنه با یک الگوریتم غیرعلمی همین چیزهاست.
هرچند بنظر من اشکال اینطور الگوریتم ها بزرگتر از این حرفهاست که بگیم برای کاربردهای معمولی مشکلی ندارن.
وقتی ترافیک سایت خیلی زیاد بشه احتمال برخوردها خیلی بالا میرن چون زمانبندی های عادی خیلی تغییر میکنن و سرور در کل کند میشه. همچنین در شرایط و الگوریتم های خاص این مسائل براحتی بروز میکنن و به اشکالات پنهان و خیلی سخت برای پیدا کردن منشاء تبدیل میشن.
ضمنا شما فرض کردید که یک برنامه فقط یک ارتباط دیتابیس داره و در این میان کار دیگه ای نمیکنه که زمان قابل توجهی ببره؛ و خود این فرض هم کاملا غلط هست. برنامه باید طوری طراحی بشه که اگر در بین دستورات دیتابیس دستور و عملیات دیگری قرار داشت یا بعدا در اونجا قرار گرفت که ترتیب اجرا رو از نظر زمان دستخوش تغییر میکرد، باعث قاط زدن کل سیستم نشه!! وگرنه چنین برنامه ای بعدها در شرایط خاص یا با توسعه و تغییر توسط دیگرانی یا حتی خود شما، ممکنه خراب بشه و تشخیص علت اون حتی برای خودتون هم کار بسیار سختی خواهد بود. این یک نمونه هست که نشون میده قابلیت توسعه پذیری و نگهداری برنامه های ضعیف و کدهای حرفه ای چطور با هم تفاوت دارن.
یه وقتی حتی به علتهایی خارج از خود برنامهء شما، زمانبندی های اجرا بهم میخورن. مثلا بین اجرای دو دستور دیتابیس از نظر تئوری میتونه حتی تا چند ثانیه فاصله بیفته. این ممکنه برای یک صفحه یا چند صفحه رخ بده و بستگی به برنامه ها و عملیات دیگری که در کل اجزای دیگر سرور صورت میگیرن داره. یعنی کسی به شما تضمینی نمیده که برنامهء شما دقیقا با چه زمانبندی ای اجرا بشه و این وظیفهء مسلم برنامه نویس هست که بر زمانبندی دقیقی اتکا نکنه. ممکنه برنامهء شما یک ماه، یک سال، یا حتی چند سال درست کار کنه، ولی با وقوع یکی از این شرایط و شانس بد شما که بالاخره وقوعش مورد انتظار بوده، سیستم شما دچار اختلال در کارکرد میشه. خب این احتمال و زمانها بستگی به خیلی شرایط دارن که باید با توجه به شرایط هر موردی برآورد کرد. اما این تحلیل ها فقط یک ضعف و مشکل برنامه نویسی رو تحلیل میکنن، نه توجیه و ارائهء راه حل! وقتی راه حل اصولی ای وجود داره، باید از راه حل اصولی استفاده بشه! غیر از اینه؟
شما فکر کنید کل این مجموعهء عظیم سیستم عامل شما و اینترنت و تمام برنامه ها و سیستمهای رایانه ای که دنیای ما رو با الگوریتمهاشون اداره میکنن اگر هرکدوم یکی از این اشکالات رو داشته باشن، اصلا هیچی کار نخواهد کرد و هر ثانیه یک مشکل در یک جای سیستم عامل و رایانهء شما یا در اینترنت و وب بوجود میاد که همه چیز رو بحالت هنگ میبره!!
در سیستم عامل پردازشها و سیستمهای مختلفی هست و این الگوریتم ها و شرایط تمام سیستم عامل و برنامه هاش هستن که مشخص میکنن کدوم برنامه دقیقا چه زمانی اجرا بشه. ممکنه اجرای یک برنامه حتی در نیمهء اجرای اون موقتا برای زمان کوتاه یا حتی قابل توجهی به حالت تعلیق دربیاد. میدونید که در اغلب پردازشهای عادی هم ما Priority داریم و پردازشهای با اولویت بالاتر بر پردازشهای با اولویت پایینتر تقدم اجرا دارن. خلاصه در کل داستان پیچیده هست و به خیلی عوامل بستگی داره و اصلا قابل پیشبینی و اتکا نیست.
ممکنه ادمین سرور یه برنامهء خاصی رو روی سرور در زمان خاصی اجرا کنه، یا اصلا شرایط خاصی بعلت خاصی در سرور پیش بیاد. هزار و یک امکان و حالت هست. از حمله های DOS گرفته تا اجرای یک بکاپ و خیلی مسائل دیگه.
شما میتونید با قرار دادن چند دستور Sleep در جاهای مختلف الگوریتم خودتون، شرایط خاصی رو که در سرور پیش میان، یعنی در کل در اجرای برنامهء شما، تست کنید. اونوقت میبینید که چی میشه! البته درست کردن تست هوشمندانه و دقیق هم خیلی وقتها نیاز به دانش و مهارت داره و بعضی وقتها خیلی مشکله یا بخاطر کمبود امکانات سخت افزاری و نرم افزاری مورد نیاز حتی غیرممکنه که در عمل بشه شبیه سازیش کرد و در این موارد باید برنامه نویس اونقدری دانش و مهارت ذهنی و تئوریک داشته باشه تا بتونه بصورت ذهنی مسائل رو تحلیل و پیشبینی بکنه و براشون راههای جلوگیری در الگوریتم پیاده سازی بکنه.

شما خودتون اوقاتی رو دیدید که PC شما و سیستم عامل و برنامه هاش خیلی کند میشن یا اصلا کم و بیش به حالت تعلیق درمیان. حداقل بعضی از اونها. چنین شرایطی غیرمعمول نیستن. در سرور هم بعضی اوقات چنین شرایطی هرچند برای بازه های زمانی کوتاهتر ممکنه پیش بیان. ضمن اینکه همونطور که گفتم اصلا درمورد اینطور الگوریتم ها باید گفت بیش از اینها ایراد دارن و وقوع اختلال در اونها احتمال خیلی بالاتری داره بنظرم.

یه کمی درمورد Race condition هم میتونید مطالعه کنید.
اگر با اصول ظریف برنامه نویس چندنخی آشنایی کامل داشته باشید درک واقعیت و اهمیت این موارد برای شما خیلی ساده تر هست.

[eshpilen]

فك كنم update set counter=counter+1 از همه چي راحت تر باشه!!!

خیلی وقته از خوندن رفرنس MySQL میگذره! یادم نیست این ساختار چه خصوصیاتی داره. الانم وقت ندارم برم دنبالش. ببخشید!
البته احتمالش زیاده برای این کاربرد دقیقا درست و مناسب باشه، ولی مطمئن نیستم. کل ساختار باید اتمیک باشه. باید دید رفرنس در اینمورد چی میگه. ولی فکر میکنم همینطور باشه.
اگر اطلاعات بیشتری داشتی در تاپیک بذار. ضمنا این چه وضعشه، یه دستور کامل و دقیق بذار که سر و تهش معلوم باشه!!
اما روشی رو که بنده پیشنهاد کردم بخاطر این هست که بنظرم روی هر نوع دیتابیسی در هر شرایطی درست جواب میده و دیگه توش شک و تردید نیست. ضمنا چون درواقع بغیر از شمارش، اطلاعات دیگری از کاربر مثل نوع مرورگر و Referrer و IP و غیره رو هم ثبت میکنم، روشی که پیشنهاد کردم روش مناسب و کافی هست. یعنی بهرصورت باید به ازای هر کاربر یک رکورد درج کنیم، پس چه بهتر که شمارنده رو هم از طریق همین کدها پیاده سازی کنیم (با یک تیر دو نشان!). تقریبا هیچ کدنویسی اضافه ای هم نداره.

درواقع موقعی که میخواستم شمارندهء خودم رو درست کنم، وقت و حالش رو نداشتم که بازم بصورت دقیق جستجو کنم و کلی مطلب و رفرنس بخونم و دست آخر بازم روزهء شک دار بگیرم و مطمئن نباشم و برنامه بیخودی پیچیده و وابسته به عوامل خارجی بشه. بخاطر همین به فکر یک روش افتادم که بدون مشکل بودنش بدیهی و پیاده سازیش ساده و سریع باشه. اینه که به روش درج یک رکورد به ازای هر کاربر رسیدم؛ ضمن اینکه همراهش اطلاعات جانبی دیگری رو هم درج میکنیم. ضمنا وقتی یک کار دیتابیسی رو به ازای هرکاربر انجام میدیم، بنظرم هزینه های عمدهء ارتباط با دیتابیس و غیره پرداخت شدن، پس ثبت یک مقدار اطلاعات جانبی بیشتر، ضرر خاصی نمیزنه و میتونه استفادهء بهینه باشه و از اطلاعات ثبت شده بعدا برای چیزهایی مثل آمارهای مختلف یا حتی موارد امنیتی استفاده کرد. خوبی دیگرش هم اینه که به وجود و خصوصیات دستورات خاصی در DBMS وابسته نیست و میتونه در هر جایی با هر سرور دیتابیسی با اطمینان بکار بره.

البته روش خوبی معرفی کردی. بنظرم درسته.

[shahriyar3]

eshpilen گرامی
ماشالا چه حوصله ای داری که این همه نشستی تایپ کردی
عزیز من همه چیز که قرار نیست از اول تا آخر بر عهده یه اسکریپت چند خطی باشه که!!
داخل هسته سیستم عامل زمانبندی اجرا وجود داره عزیز من. چندین مدل الگوریتم های زمان بندی وجود داره که جلوی این تداخل ها رو میگیره.شما یه کتاب در این مورد بخونید مشکل حل میشه
به این سختی ها هم که شما میفرمائید نیست.
چندین دستور به طور همزمان و موازی به سمت سیستم عامل ارسال میشن اونجا توسط هسته سیستم عامل در نوبت اجرا قرار میگیرن و بر اساس الگوریتم تعبیه شده اجرا میشن حالا این الگوریتم میتونه نسبی باشه یا تفکیکی.خیلی بحث تئوری جالبی هست که پیشنهاد میکنم حتما مطالعه بکنید
این اسکریپت های شمارنده از نظر اجرا و زمانبندی و خروجی مشکلی ندارند البته من منکر الگوریتم های بهینه تر نیستم ولی نه به اون پیچیدگی که شما فرمودید!

[eshpilen]

عزیز برادر حتی برای دستوراتی مثل i++ در برنامه نویسی توابع/کلاسهای ویژه ای ویژه وجود دارن که از تداخل پراسس ها یا تردهای مختلف جلوگیری بشه. یعنی تداخل این کارها رو بطور خودکار نه کامپایلر و نه سیستم عامل مدیریت نمیکنن، بلکه برنامه نویس باید حواسش باشه و پیاده کنه. و چیزهای ساده ای مثل افزایش یک واحد به یک متغییر، اونم با عملگر ++، درواقع Atomic نیستن و بین خواندن مقدار متغییر تا افزایش و ذخیرهء مقدار جدید ممکنه یک ترد یا پردازش دیگر محتوا رو دستکاری بکنه. حالا شما بفرمایید کجا کدوم الگوریتم های زمانبندی و نوبت اجرا وجود دارن؟ سندش کجاست؟ وقتی برای یک افزایش متغییر در حافظه چنین چیزی نداریم، شما فکر میکنید بین دستورات مختلف PHP و کوئری های دیتابیس چنین مکانیزم خودکاری وجود داره؟ اصلا همچین چیزی نیست. شما نمیدونید از چی دارید صحبت میکنید.
سند حرفهایی هم که بنده میزنم موجوده. ساختارهای افزایش مقدار متغییر بصورت Thread safe در دات نت وجود دارن که چند وقت پیش که داشتم رفرنس کتابخانهء استاندارد رو میخوندم بهشون برخوردم.
درمورد مشکل شمارنده های سایت هم میتونم با مثال عملی بهتون نشون بدم. اگر خواستید بگید یک نمونه براتون بذارم.

[eshpilen]

هستهء سیستم عامل کجا بود! هستهء سیستم عامل که از همه جا خبر نداره. یه چیزی همینطوری نپرون عزیز برادر. من اگر زیاد مینویسم درست مینویسم. اما شما یه چیزی که اصلا خودت هم سر و تهش رو نمیدونی و صرفا حدس میزنی و سند و استدلال محکمی براش نداری همینطوری میندازی وسط که حکایت انداختن سنگ به ته چاه هست که صدتا عاقل هم نمیتونن درش بیارن.
هستهء سیستم عامل از جریانات منطق و هدف برنامهء شما اونم بین دو نرم افزار و لایه های مختلف مثل PHP و MySQL هیچ خبری نداره که بخواد در این زمینه تمهیدی انجام بده. هستهء سیستم عامل حتی از ارتباط کوچکترین دستورات یک قطعه از برنامهء شما هم خبر نداره و الگوریتمی برای مدیریت داخلی منطق برنامهء شما و حتی تک دستوراتی مثل i++ نداره.
چیزهایی هم که بنده به شما گفتم از نظر اصولش درست هست، ولی نشون دادن عملی بعضی از اونها سخت یا ناممکن هست، چون احتمال وقوع کمی دارن یا در شرایط خاصی رخ میدن که ما اگر بخوایم اونها رو مثلا با روشهای دیگری مثل ایجاد تاخیر عمدی در اجرای برنامه شبیه سازی کنیم، لابد شما باز میای و یه حرف دیگه میزنی و میگی نه!

حالا این الگوریتم میتونه نسبی باشه یا تفکیکی.خیلی بحث تئوری جالبی هست که پیشنهاد میکنم حتما مطالعه بکنید

منظورتون از نسبی و تفکیکی چی هست و چی رو پیشنهاد میکنید مطالعه کنم؟! منبعش کجاست؟

[eshpilen]

مثلا شما فرق همین update set counter=counter+1 رو با اینکه مقدار متغییر رو در PHP افزایش بدیم میدونید؟
این دستور توسط خود MySQL اجرا میشه و روش قفل صورت میگیره. یعنی تا زمانیکه کار این دستور تمام نشده، هیچ پردازش دیگری نمیتونه به اون رکورد و فیلد خاص دسترسی داشته باشه. البته این قفل میتونه قفل کامل نباشه و مثلا اجازهء خواندن بدن، اما اجازهء نوشتن و اجرای دستور مشابه رو نده.
خلاصه همین چیزها که شما میگید ساده هست درواقع ساده نیستن و کاملا حساب شده هستن.
فکر کنید چرا MySQL برای این دستور از Lock استفاده میکنه؟ و وقتی شما این کار رو در داخل PHP انجام میدید آیا قفلی وجود داره و اگر وجود نداره آیا نیاز نبود؟
سیستم عامل چنین چیزهایی رو حتی داخل یک برنامهء منفرد هم نمیدونه و کنترل نمیکنه. چه برسه موقعی که شما با ارتباط چند برنامه و لایه های مختلف سروکار دارید. اگر سیستم عامل اینها رو میدید و مدیریت میکرد، MySQL نیازی نداشت یک Lock پیاده کنه. MySQL هم نهایتا دیتای خودش رو روی دیسک سخت و در یک فایل ذخیره میکنه و هر ارسال و دریافت اطلاعاتی توسط MySQL، اول و آخر از لایهء سیستم عامل عبور میکنه و سرویسهای فایل رو سیستم عامل در اختیار قرار میده.

[shahriyar3]

ماشالا شما خیلی وقت آزاد داری دوست من
هر پردازشی که بخواد cpu انجام بده بوسیله سیستم عامل و توسط الگوریتم های زمان بندی بهش ارجاع داده میشه.
حالا چه چیز هائی میتونه توسط cpu پردازش بشه ؟ مثلا همین عمل جمع بوسیله موتور php به cpu (به واحد محاسبه و منطق ALU)توسط الگوریتم های زمانبندی سیستم عامل ارجاع داده میشه.
موتور php نسخه های متفاوتی برای سیستم عامل های متفاوت دارد از جمله ویندوز یا لینکوس
-------------------------

سند حرفهایی هم که بنده میزنم موجوده.

دوست عزیز دست از این نوع ادبیات چندش آور بردار! این مدل صحبت کردن من و یاده یکسال و نیم پیش میاندازه

[eshpilen]

عجب!
ماشالا چقدر چیزای زیاد و دقیق و پیچیده ای شما میدونی

بهتره به جملاتی از یک فرد دیگر که در فروم دیگه در تاپیک مشابه زده توجه کنی شاید دوزاریت بیفته (البته اگر خودت رو نزده باشی به اون راه):

بله روشي كه بالا گفتم كاملا درست عمل ميكنه چرا كه تك دستور بخودي خود ترنس اكشن هست و اتميسيتي ش تضمين شده هست ولي اگر لازم باشه ماي اسكيوال ميتونه با دستور ترنس اكشن هم كار كنه هرچند در اين مثال نيازي نيست.
...
ميدوني كه هر بار كه ميخواي آپديت انجام بدي جدول يا بخشي از اون لاك ميشه.

خود تاپیک مربوطه: https://gozareforum.com/thread-3097.html?s=c803de57&

همینطور که در این گفته میبینید، در چنین مواردی پیاده سازی مکانیزمهایی مثل قفل، برای جلوگیری از دسترسی همزمان مخرب لازمه و این کار بعهدهء برنامه و برنامه نویس هست و بصورت خودکار توسط سیستم عامل و هر بخش دیگری انجام نمیشه.
MySQL این مکانیزم رو بصورت درونی پیاده کرده، و شما میتونید از امنیت MySQL در این زمینه به نحوی، مثل روشی که بنده معرفی کردم یا روشی که دوستمون میگه، استفاده کنید. وگرنه اگر نصف کد Critical شما در کوئری MySQL بود و نصف دیگش در PHP، انتظار نداشته باشه MySQL یا PHP یا سیستم عامل و یا هر بخش و سیستم دیگری برات همه چیز رو راست و ریس کنن!

دوست عزیز دست از این نوع ادبیات چندش آور بردار! این مدل صحبت کردن من و یاده یکسال و نیم پیش میاندازه

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

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

[lovephp]

در چنین مواردی پیاده سازی مکانیزمهایی مثل قفل، برای جلوگیری از دسترسی همزمان مخرب لازمه و این کار بعهدهء برنامه و برنامه نویس هست و بصورت خودکار توسط سیستم عامل و هر بخش دیگری انجام نمیشه.
MySQL این مکانیزم رو بصورت درونی پیاده کرده، و شما میتونید از امنیت MySQL در این زمینه به نحوی، مثل روشی که بنده معرفی کردم یا روشی که دوستمون میگه، استفاده کنید. وگرنه اگر نصف کد Critical شما در کوئری MySQL بود و نصف دیگش در PHP، انتظار نداشته باشه MySQL یا PHP یا سیستم عامل و یا هر بخش و سیستم دیگری برات همه چیز رو راست و ریس کنن!

من تو زمینه معماری سیستم عامل هرچند مطالعات خیلی کمی داشتم اما این موضوع برام ثابت شده
چون سیستم عامل لایه های بالایی رو که به طور کامل تحت نظر نداره و خود اونها مثل همین مای اس کیو ال طوری طراحی شدن که در صورت نیاز از سیستم عامل بخوان که مثلا فلان فایل رو روی سیستم فایل (منظورم یه جدوله مثلا) تا موقعی که من میگم قفل کن چون من دارم روی این فایل تغییرات میدم (رکود ویرایش میکنم) نباید توسط برنامه دیگری تغییری روش داده بشه تا کارم تموم بشه
بعد از آپدیت شدن جدول هم دوباره به سیستم عامل میگه من کارم تموم شده حالا قفل فایل رو باز کن
وگرنه خود سیستم عامل که نمیتونه خودشو با هزارن نرم افزار که هستن و دارن تولید میشن تعامل داشته باشه و از تموم مکانیسمهای اونا از قبل اطلاع داشته باشه
خودم هم نفهمیدم چی گفتم اصلا




ب

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

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

کاملا موافقم با این حرفا