আমার কি এমন দৌড়ের অবস্থার যত্ন নেওয়া উচিত যা প্রায়শই ঘটে যাওয়ার কোনও সম্ভাবনা নেই?

Question

আসুন আমরা জিইউআই অ্যাপ্লিকেশনটির মতো কিছু বিবেচনা করি যেখানে মূল থ্রেডটি তাত্ক্ষণিকভাবে ইউআই আপডেট করে এবং অন্য কিছু থ্রেডটি নেটওয়ার্কের উপরে পোলিং ডেটা বা এমন কিছু যা কাজ শেষ করতে 5-10 সেকেন্ড সময় নেওয়ার নিশ্চয়তাযুক্ত।

আমি এর জন্য অনেকগুলি বিভিন্ন উত্তর পেয়েছি, তবে কিছু লোক বলে যে এটি যদি কোনও পরিসংখ্যানগত অসম্ভবতার দৌড়ের অবস্থা হয় তবে একেবারেই চিন্তা করবেন না তবে অন্যরা বলেছেন যে যদি এখানে একটি 10 ^-53 % (আমি ছাগলছানা) থাকে তবে আপনি সংখ্যায় নেই, আমি এটি শুনেছি) রেড শর্তের কারণে কিছু ভুডু যাদু ঘটছে, সর্বদা থ্রেডের জন্য প্রয়োজনীয় লকগুলি / রিলিজ পান release

আপনার চিন্তা কি? এই জাতীয় পরিসংখ্যান-অসম্ভব পরিস্থিতিতে জাতি অবস্থা পরিচালনা করা কি ভাল প্রোগ্রামিং অনুশীলন? বা পাঠযোগ্যতা বাধাগ্রস্থ করতে কোডের আরও লাইন যুক্ত করা কি সম্পূর্ণ অপ্রয়োজনীয় বা এমনকি প্রতিকূল উত্পাদক হবে?

Comments

লোকেরা যখন সম্ভাবনার কথা বলছে তখন কেন কেউ এই সংখ্যাটি উল্লেখ করে তার লেখাপড়া সম্পর্কে জিজ্ঞাসা করবে না? এই জাতীয় সংখ্যার সাথে ব্যাকআপ নেওয়ার আগে আপনার পরিসংখ্যানগুলিতে একটি আনুষ্ঠানিক শিক্ষা প্রয়োজন।

— পিটার বি

পদার্থবিজ্ঞানী হিসাবে, পি <1E-140 অর্থ পি = 0। এই মহাবিশ্বে ঘটবে না। 0.00000000000000000000000000000000000000000000000000001% অনেক বড়।

— এমসাল্টার্স

নিশ্চিত হয়ে নিন যে এই রেসের শর্তটি কেউ আপনার অ্যাপ্লিকেশনটিকে স্বেচ্ছায় ক্রাশ করতে না পারে । এটি কোনও সুরক্ষা সমস্যার কারণ হতে পারে।

— toasted_flakes

দশ মিলিয়নে একজনের মধ্যে দশজনের মধ্যে নয় বার ঘটে থাকে।

— কাজ ড্রাগন

"প্রায় অবশ্যই ঘটনার কোন সম্ভাবনা নেই?" এর অর্থ এটি উত্পাদিত হয় সকাল 3 টায় এবং সম্ভবত খুব ব্যয়বহুল।

Answer 1

যদি এটি 10 ​​10 55 ইভেন্টে সত্যই 1 হয় তবে এটির জন্য কোড করার দরকার নেই। এর দ্বারা বোঝা যাবে যে আপনি যদি দ্বিতীয় সেকেন্ডে 1 মিলিয়ন বার অপারেশন করেন তবে আপনি প্রতি 3 * 10 ^ 41 বছরে একটি বাগ পাবেন যা মোটামুটি, মহাবিশ্বের বয়সের 10 - 31 বার। যদি আপনার অ্যাপ্লিকেশনটির মহাবিশ্বের প্রতি ট্রিলিয়ন ট্রিলিয়ন বিলিয়ন যুগে কেবল একবার ত্রুটি থাকে তবে এটি সম্ভবত যথেষ্ট নির্ভরযোগ্য।

যাইহোক, আমি খুব ভারীভাবে বাজি ধরব যে ত্রুটিটি সম্ভবত এর সম্ভাবনার কাছাকাছি নয়। আপনি যদি ত্রুটিটি সম্পর্কে ধারণা করতে পারেন তবে এটি প্রায় নিশ্চিত যে এটি অন্তত মাঝেমধ্যে ঘটবে এবং এর ফলে এটি সঠিকভাবে কোডিংয়ের পক্ষে শুরু হয়ে যায়। এছাড়াও, আপনি যদি সূচনাগুলিতে শুরুতে সঠিকভাবে কোড করেন যাতে তারা লকগুলি যথাযথভাবে প্রাপ্ত এবং প্রকাশ করে, ভবিষ্যতে কোডটি অনেক বেশি রক্ষণাবেক্ষণযোগ্য। আপনার যখন কোনও পরিবর্তন করার দরকার হয় তখন আপনাকে সমস্ত সম্ভাব্য জাতি অবস্থার পুনরায় বিশ্লেষণ করতে হবে, তাদের সম্ভাবনাগুলি পুনরায় গণনা করতে হবে এবং নিজেকে নিশ্চিত করুন যে তারা পুনরুক্ত হবে না।

Comments

আমি কয়েক বছর আগে পড়েছিলাম এমন একটি মন্তব্যের কথা মনে করিয়ে দিচ্ছি তবে এখন "মিলিয়ন সুযোগে এ 1 সাধারণত পরের মঙ্গলবার" পাই না। এটি "সম্ভাব্যতার কাছাকাছি কোথাও নেই" বলার জন্য +1।

— বেভান

বাজির জন্য +1। জাতিদের পরিস্থিতি মোকাবিলার সর্বোত্তম উপায় হ'ল এগুলি থেকে মুক্তি পাওয়া।

— blrfl

@ বিভান "মিলিয়ন চান্সে এ 1 সাধারণত পরের মঙ্গলবার হয়" ... যদি আপনি লটারি না খেলেন :)

— ড্যাসব্লিংকনলাইট

@ ড্যাসব্লিংকনলাইট তবে বেশিরভাগ লটারিতে কেউ বিজয়ী হওয়ার সম্ভাবনা ১০০% এর কাছাকাছি পৌঁছেছে। প্রেডিক্টিং যারা , এখন যে চ্যালেঞ্জ।

— বেভান

@Bevan: যে মন্তব্য করা হয়েছে আমার মন মাধ্যমে ঠিক কি যেতাম যখন আমি প্রশ্ন পড়া - এখানে রেফারেন্স: blogs.msdn.com/b/larryosterman/archive/2004/03/30/104165.aspx

— ডক ব্রাউন

Answer 2

ব্যয়-বেনিফিট দৃষ্টিকোণ থেকে আপনার অতিরিক্ত কোডটি কেবল তখনই লেখা উচিত যখন এটি আপনার যথেষ্ট সুবিধা পায়।

উদাহরণস্বরূপ, যদি কোনও খারাপ থ্রেড "রেস জয়ী হয়" তবে সবচেয়ে খারাপটি ঘটবে তা হ'ল তথ্যটি প্রদর্শিত হবে না এবং ব্যবহারকারীকে "রিফ্রেশ" ক্লিক করতে হবে, জাতি শর্তের বিরুদ্ধে রক্ষা করা বিরক্ত করবেন না: প্রচুর কোড লিখুন এমন কোনও কিছুকে তুচ্ছ করে ফিক্স করার মতো নয়।

অন্যদিকে, যদি রেসের শর্তের ফলে ব্যাংকিং অ্যাকাউন্টগুলির মধ্যে ভুল অর্থ স্থানান্তর হতে পারে, তবে আপনাকে অবশ্যই এই সমস্যাটি সমাধান করার জন্য কত কোড লিখতে হবে তা বিবেচনা করে অবশ্যই রেসের শর্তের বিরুদ্ধে রক্ষা করতে হবে।

Comments

+1: "ব্যর্থতার মতো দেখতে ব্যর্থতা" এবং "সাফল্যের মতো দেখতে ব্যর্থতা" এর মধ্যে পার্থক্য তৈরি করার জন্য। ডোমেনের উপর নির্ভর করে ভুল তথ্য অনেক বেশি গুরুতর।

— ডিফোরে

+1 এটি রেসের শর্তের ফলাফল কী হতে পারে তা একটি বড় পার্থক্য করে।

— অনুদান দিন

+1 প্রতিযোগিতার শর্তের পরিণতিটি যদি বিবেচনা করা উচিত তবে তার মধ্যে একটি বড় সিদ্ধান্ত নেওয়া উচিত। একটি বিমানের শর্ত যা বিমানের ক্রাশের কারণ হতে পারে এমন অবস্থার থেকে অনেকটাই আলাদা যা ব্যবহারকারীকে কোনও অ্যাপ্লিকেশন পুনরায় খুলতে বাধ্য করতে পারে।

— অকর্মা

+1: আমি বলব যে পরিণতিগুলি সম্ভবত আপনার বিশ্লেষণ করা উচিত এবং এর সম্ভাব্যতা না ঘটে। যদি পরিণতিগুলি গুরুত্ব দেয় না, তবে রেস শর্তটি খুব সাধারণ হলে আপনাকে পরিচালনা করতে হবে না।

— লিও

তবে ধরে নিবেন না যে রেসের শর্তটি স্বয়ংক্রিয়ভাবে স্থির করার অর্থ আপনাকে আরও কোড লিখতে হবে। এটি ঠিক পাশাপাশি বোঝাতে পারে বগি কোডের একটি বিশাল অংশটি সরিয়ে এবং সঠিক কোডের একটি ছোট অংশের সাথে এটি প্রতিস্থাপন করবে।

— জেস্পের ই

Answer 3

একটি রেসের শর্ত সন্ধান করা কঠিন অংশ। আপনি সম্ভবত এই প্রশ্নটি লেখার জন্য প্রায় যতটা সময় ব্যয় করেছেন এটি ঠিক করার জন্য আপনাকে যেমন গ্রহণ করেছিল। এটি এটিকে এত কম পাঠযোগ্য করে তোলে এমনটি নয়। প্রোগ্রামাররা এমন পরিস্থিতিতে সিঙ্ক্রোনাইজেশন কোডটি দেখতে প্রত্যাশা করে এবং আসলে এটি কেন নেই তা ভেবে আরও বেশি সময় নষ্ট করতে পারে এবং এটি যুক্ত করা থাকলে তাদের সম্পর্কযুক্ত বাগটি ঠিক করবে।

সম্ভাব্যতার দিক থেকে আপনি অবাক হবেন। আমার কাছে গত বছর রেসের শর্তের বাগ রিপোর্ট ছিল যে আমি হাজার হাজার স্বয়ংক্রিয় চেষ্টা করে পুনরুত্পাদন করতে পারিনি, তবে একটি গ্রাহকের একটি সিস্টেম সর্বদা তা দেখেছিল। এখনই এটি ঠিক করতে 5 মিনিট ব্যয় করার ব্যবসায়িক মূল্য, কোনও গ্রাহকের ইনস্টলেশনতে সম্ভবত "অসম্ভব" বাগটি সমস্যা সমাধানের বিপরীতে, পছন্দটিকে কোনও মস্তিষ্কে পরিণত করে।

Comments

এটাও! আপনার কোডটি পড়ার সময় অন্যান্য প্রোগ্রামারদের সম্ভাব্য সমস্যাগুলি নিয়ে চিন্তা করা থেকে বিরত থাকুন, প্রয়োজনীয় জিনিসগুলি করে (এমনকি এটি 'সম্ভাব্য' ব্যর্থ হওয়ার সম্ভাবনাও রয়েছে কিনা))

— কেসি কুবাল

আপনার পয়েন্টটি ভালভাবে নেওয়া হয়েছে (এখনকার সংশোধনগুলি পরে তৈরি করাগুলির তুলনায় দ্রুত এবং সস্তা) ব্যতীত এটি এখনই ঠিক করার জন্য কেবল "5 মিনিট" হবে না।

— আইকনোক্লাস্ট

+1 উল্লেখ করার জন্য যে রেসের শর্তের সম্ভাবনা সম্ভবত অনেকগুলি বিষয়ের উপর নির্ভর করে, সুতরাং এটি আপনার কনফিগারেশনে অসম্ভব মনে হলেও এটি গ্রাহক সিস্টেমে / পরবর্তী রিলিজে অন্য কোনও OS / এ আরও ঘন ঘন ঘটতে পারে

— sleske

Answer 4

লকগুলি পান এবং ছেড়ে দিন। সম্ভাবনা পরিবর্তন হয়, অ্যালগরিদম পরিবর্তন হয়। এটি একটি খারাপ অভ্যাস aোকা এবং যখন কিছু ভুল হয়ে যায় তখন আপনাকে থামাতে হবে না এবং ভাবতে হবে না যে আপনার প্রতিক্রিয়াগুলি ভুল হয়েছে কিনা ...

Comments

অ্যালগরিদম পরিবর্তনের জন্য +1। এই মুহুর্তে, আপনি যখন রেসের অবস্থা সম্পর্কে সচেতন হন, সম্ভাবনা কম থাকে। এক বছর পরে, আপনি যখন রেসের শর্তটি ভুলে গেছেন, আপনি আপনার কোডটিতে পরিবর্তন করতে পারেন যা বাগের সময় এবং সম্ভাবনার উল্লেখযোগ্য পরিবর্তন করে।

— ফিল

Answer 5

এবং অন্য কিছু থ্রেড হ'ল নেটওয়ার্ক বা এমন কোনও কিছুতে পোলিং ডেটা যা কাজ শেষ করতে 5-10 সেকেন্ড সময় নেওয়ার গ্যারান্টিযুক্ত।

কর্মক্ষমতা উন্নত করতে কেউ কোনও ক্যাচিং স্তর প্রবর্তন না করা পর্যন্ত। হঠাৎ করে অন্যান্য পদক্ষেপগুলি তাত্ক্ষণিকের কাছাকাছি পৌঁছে গেল এবং দৌড়ের অবস্থাটি প্রায়শই না ঘটে।

কয়েক সপ্তাহ আগে ঠিক এটি ঘটলে, বাগটি খুঁজে পেতে প্রায় 2 টি পূর্ণ বিকাশকারী দিন সময় নেয়।

আপনি যদি জাতিগুলির শর্তাদি চিনেন তবে সর্বদা ঠিক করুন

Answer 6

সহজ বনাম সঠিক।

অনেক ক্ষেত্রে, সরলতা নির্ভুলতা ট্রাম্প। এটি একটি ব্যয় সমস্যা।

এছাড়াও, বর্ণের শর্তগুলি এমন বাজে জিনিস যা সাধারণ পরিসংখ্যান মানায় না। অন্য কিছু আপাতদৃষ্টির সাথে সম্পর্কিত না হওয়া অবধি সুসংহতকরণ না হওয়া পর্যন্ত সবকিছু ঠিকঠাক হয়ে যায় যতক্ষণ না আপনার রেসের অবস্থা হঠাৎ অর্ধেক সময়ের মধ্যে ঘটে। আপনি যদি লগগুলি চালু না করেন বা কোর্সের কোডটি ডিবাগ না করেন।

একটি দৌড় পরিস্থিতি রোধ করার একটি ব্যবহারিক বিকল্প (যা জটিল হতে পারে) এটি সনাক্ত এবং লগ করা (কঠিন এবং প্রথম দিকে ব্যর্থ হওয়ার জন্য বোনাস) হতে পারে। যদি এটি কখনও না ঘটে তবে আপনি কিছুটা হেরে গেছেন। এটি যদি সত্যিই ঘটে থাকে তবে অতিরিক্ত সময় নির্ধারণের জন্য আপনি দৃ jus় সমর্থন পেয়েছিলেন।

Comments

লগিংয়ের জন্য +1 এবং তাড়াতাড়ি ঠিক করা খুব জটিল হলে তাড়াতাড়ি ব্যর্থ।

— মার্টিন বা

অনেক ক্ষেত্রে, সরলতা সম্পূর্ণতা ট্রাম্প। এই ক্ষেত্রে সিঙ্ক্রোনাইজেশন প্রায় কখনও হয় না। এটি প্রায় সর্বদা আপনাকে কামড়ানোর জন্য ফিরে আসবে (বা আপনার কোডটি বজায় রাখার দরিদ্র লোকটি) পরে।

— রিয়ারাব

@ রিরাব আমি একমত নই আপনি যদি বিরল ঘটনা বিবেচনা করেন তবে লগড ব্যর্থতা ব্যয়বহুল। একটি উদাহরণ: যদি আপনার ফোন অ্যাপ্লিকেশনটিতে 1/100 ব্যর্থতার হার (ক্র্যাশ) থাকে তবে যদি ব্যবহারকারী সঠিক মাসের ট্রানজিশনে নেটওয়ার্ক স্যুইচ করে থাকেন (1/31 23:59:00 -> 2/1 00:00:00), আপনি 'সম্ভবত এটি সম্পর্কে কখনও শুনতে পাবেন না। তবে তারপরে কোনও সার্ভারে সংযোগে ক্রাশ হওয়ার 1/10 ^ 9 সম্ভাবনা অগ্রহণযোগ্য। এটা নির্ভর করে.

— পিটিএক্স

Answer 7

যদি আপনার জাতি-শর্তটি সুরক্ষা সম্পর্কিত হয় তবে তা প্রতিরোধের জন্য আপনার সর্বদা কোড করা উচিত।

একটি সাধারণ উদাহরণ হ'ল ইউনিক্সে ফাইল তৈরি / খোলার সাথে রেস শর্ত, যা কোনও পরিস্থিতিতে যদি ব্যবহারকারীর সাথে ইন্টারঅ্যাক্ট করার চেয়ে উচ্চতর সুবিধাসমূহের সাথে চালিত হয় যেমন সিস্টেম ডেমন প্রক্রিয়া অথবা আরও খারাপ, কার্নেল।

এমনকি যদি কোনও রেসের শর্তটি এলোমেলোভাবে হওয়ার সম্ভাবনা 10 ^ (- 80) এর মতো কিছু থাকে তবে এটি সম্ভবত ভাল হতে পারে যে কোনও দৃ determined়প্রতিজ্ঞ আক্রমণকারী ইচ্ছাকৃতভাবে এবং কৃত্রিমভাবে এ জাতীয় পরিস্থিতি তৈরি করার উপযুক্ত সুযোগ পায়।

Answer 8

Therac-25!

থেরাক -২৫ প্রকল্পের বিকাশকারীরা থেরাপিউটিক এক্সআরএ মেশিনে ইউআই এবং ইন্টারফেস সম্পর্কিত সমস্যার মধ্যে সময় নির্ধারণের বিষয়ে যথেষ্ট আত্মবিশ্বাসী ছিলেন।

তাদের হওয়া উচিত হয়নি।

আপনি এই বিখ্যাত জীবন-মৃত্যুর সফটওয়্যার বিপর্যয় সম্পর্কে আরও শিখতে পারেন এখানে:

http://www.youtube.com/watch?v=izGSOsAGIVQ

অথবা

http://en.wikipedia.org/wiki/Therac-25

আপনার অ্যাপ্লিকেশনটি চিকিত্সা ডিভাইসের তুলনায় ব্যর্থতার চেয়ে কম সংবেদনশীল হতে পারে। একটি সহায়ক পদ্ধতি হ'ল ঝুঁকির এক্সপোজারকে হারের সম্ভাবনা হিসাবে পণ্য হিসাবে উত্পাদিত হতে পারে এমন সমস্ত ইউনিটগুলির জন্য পণ্যটির আয়ু ওভারের ব্যয়।

যদি আপনি আপনার কোডটি স্থায়ীভাবে তৈরি করতে বেছে নিয়েছেন (এবং এটি আপনার কাছে মনে হচ্ছে) তবে আপনার মুর আইনটি বিবেচনা করা উচিত যা আপনার সিস্টেমের অভ্যন্তরে বা বাইরের কম্পিউটারগুলি দ্রুততর হওয়ার সাথে সাথে প্রতি কয়েক বছরে বেশ কয়েকটি জিরো সহজেই কেটে যায়। আপনি যদি হাজার হাজার অনুলিপি পাঠান তবে আরও শূন্যপদ বন্ধ করুন। ব্যবহারকারীরা যদি বছরের পর বছর ধরে এই অপারেশনটি প্রতিদিন (বা মাসিক) করেন তবে আরও কয়েকটা নিয়ে যান। এটি যদি গুগল ফাইবার পাওয়া যায় সেখানে ব্যবহৃত হয়, তবে কী? যদি ইউআইয়ের আবর্জনা মাঝারি জিইউআই অপারেশন সংগ্রহ করে, তবে তা কি দৌড়কে প্রভাবিত করে? আপনি কি নিজের জিইআইয়ের পিছনে কোনও ওপেন সোর্স বা উইন্ডোজ লাইব্রেরি ব্যবহার করছেন? সেখানে আপডেটগুলি কি সময়কে প্রভাবিত করতে পারে?

থ্রেডগুলির মধ্যে ক্রিয়াকলাপগুলি সিঙ্ক্রোনাইজ করার উপায়গুলির মধ্যে সেমোফোরস, লকস, মিটেক্সেস, বাধা সংলগ্নকরণ are সম্ভবত আপনি যদি সেগুলি ব্যবহার না করে থাকেন তবে অন্য কোনও ব্যক্তি যিনি আপনার প্রোগ্রাম বজায় রাখবেন এবং তারপরে থ্রেডগুলির মধ্যে সম্পর্কের সম্পর্কে খুব দ্রুত ধারনাগুলি স্থানান্তরিত হতে পারে এবং রেসের শর্ত সম্পর্কে গণনা অবৈধ হতে পারে।

আমি আপনাকে সুস্পষ্টভাবে সিঙ্ক্রোনাইজ করার পরামর্শ দিচ্ছি কারণ আপনি কখনই এটি কোনও সমস্যা তৈরি হতে দেখছেন না, কোনও গ্রাহক হতে পারে। এছাড়াও, আপনার জাতির শর্তটি কখনও না ঘটলেও, আপনার কোডটি রক্ষার জন্য আপনাকে বা আপনার সংস্থাকে আদালতে ডাকা হলে কী হবে (যেমন টয়োটা কয়েক বছর আগে প্রিয়াসের সাথে সম্পর্কিত ছিল)। আপনার পদ্ধতিটি যত বেশি বিশদ হবে ততই ভাল আপনি ভাবেন। এটি বলার অপেক্ষা রাখে না যে "আমরা এইরকম সম্ভাব্য মামলার বিরুদ্ধে রক্ষা করি ..." বলার অপেক্ষা রাখে না, "আমরা জানি আমাদের কোডটি ব্যর্থ হবে, তবে আমাদের জীবদ্দশায় এটি ঘটবে না তা দেখানোর জন্য আমরা এই সমীকরণটি লিখেছিলাম। সম্ভবত। "

দেখে মনে হচ্ছে সম্ভাবনার গণনা অন্য কারও কাছ থেকে এসেছে। তারা কি আপনার কোড জানে এবং আপনি কি তাদের বিশ্বাসের পক্ষে যথেষ্ট জানেন যে কোনও ত্রুটি হয়নি? যদি আমি কোনও কিছুর জন্য 99.99997% নির্ভরযোগ্যতা গণনা করি, তবে আমি আমার কলেজের পরিসংখ্যান ক্লাসে ফিরেও ভাবতে পারি এবং মনে রাখতে পারি যে আমি সর্বদা 100% পাইনি এবং নিজের ব্যক্তিগত নির্ভরযোগ্যতার প্রাক্কলনে বেশ কয়েক শতাংশ ফিরে এসেছি।

Comments

থেরাক -২৫ উল্লেখ করার জন্য +1। এখানে অনেক গুরুত্বপূর্ণ পাঠ।

— স্টুয়ার্ট

যদিও আমি মনে করি এটি একটি উত্তরের উত্তর, আপনি তর্ক করতে পারেন যে আপনার শখের জিইউআই প্রকল্প অবশ্যই কোনও রেসের শর্তটি অপসারণ করতে ব্যর্থ হলে লোক অবশ্যই মারা যায় না।

— মার্কতানি

আমি তর্ক করার পক্ষে বেশি নই, তবে আমি যদি থাকি তবে আমি যুক্তি দিতে পারি যে যে কোনও সময় আমরা কোড লিখি আমাদের উচিত এটি সঠিকভাবে লেখা উচিত। যদি আমরা আমাদের শখের প্রকল্পগুলির বাইরে জাতিগুলির শর্তগুলি অর্জনের অনুশীলন করতে পারি যেখানে কোডটি সহজ এবং সম্ভবত আমরা একমাত্র লেখক, আমরা যখন কাজ প্রকল্পগুলিকে মোকাবেলা করি তখন আরও অনেক বেশি প্রস্তুত থাকব যেখানে বেশ কয়েকটি লেখকের কাজ একসাথে সংহত করা দরকার।

— বিকাশকারীরা

Answer 9

পাঠযোগ্যতা বাধাগ্রস্থ করতে কোডের আরও লাইন যুক্ত করা কি সম্পূর্ণ অপ্রয়োজনীয় বা এমনকি প্রতিক্রিয়াশীল হবে?

সরলতা কেবল তখনই ভাল যখন এটি সঠিক হয়। যেহেতু এই কোড সঠিক নয়, ভবিষ্যতে প্রোগ্রামারদের হবে অবশ্যম্ভাবীরূপে এটি তাকান যখন একটি সম্পর্কিত বাগ খুঁজছেন।

আপনি যে কোনও উপায়ে এটি পরিচালনা করেন (তা লগ ইন করে, ডকুমেন্টিং করে বা লকগুলি যোগ করে - এটি ব্যয়ের উপর নির্ভর করে) আপনি কোডটি দেখার সময় অন্যান্য প্রোগ্রামারদের সময় সাশ্রয় করবেন।

Answer 10

এটি প্রসঙ্গে নির্ভর করবে। এটি যদি একটি নৈমিত্তিক আইফোন গেম হয়, সম্ভবত না। পরবর্তী নিয়মিত মহাকাশ গাড়ির জন্য বিমান নিয়ন্ত্রণ ব্যবস্থা, সম্ভবত। এটি 'খারাপ' ফলাফলটি সংশোধন করার আনুমানিক ব্যয়ের তুলনায় পরিমাপ করা হলে পরিণতিগুলি কী হবে তার উপর নির্ভর করে।

সেখানে খুব কমই কারণ তারা হয় প্রশ্ন এই ধরনের জন্য উত্তর 'এক সাইজ সমস্ত দেখাচ্ছে' হল না প্রশ্ন, কিন্তু এর পরিবর্তে অর্থনীতি প্রশ্ন প্রোগ্রামিং।

Comments

"পরবর্তী মনুষ্যবাহী মহাকাশ গাড়ির জন্য ফ্লাইট নিয়ন্ত্রণ সিস্টেম" স্পষ্টভাবে ।

— ডিফোর্ড

সম্ভবত ... অবশ্যই ... এটি রকেটে কে ছিল তার উপর নির্ভর করবে :-)

— গ্র্যান্ডমাস্টারবি

Answer 11

হ্যাঁ, অপ্রত্যাশিত আশা করুন। আমি এমন ঘন্টাগুলি (অন্যান্য লোকের কোডে ^^) ট্র্যাকিংয়ের সময় ব্যয় করেছি যা কখনই ঘটে না।

সবসময় যেমন অন্য কিছু থাকে তার ক্ষেত্রে সর্বদা ডিফল্ট থাকে, ভেরিয়েবলগুলি সূচনা করে (হ্যাঁ, সত্যই .. বাগগুলি এর থেকে ঘটে থাকে), প্রতিটি পুনরাবৃত্তির জন্য পুনরায় ব্যবহৃত ভেরিয়েবলগুলির জন্য আপনার লুপগুলি পরীক্ষা করে ইত্যাদি

আপনি যদি বিশেষত থ্রেডিংয়ের সমস্যাগুলি সম্পর্কে উদ্বিগ্ন হন তবে এই বিষয়ে ব্লগ, নিবন্ধ এবং বই পড়ুন। বর্তমান থিমটি অপরিবর্তনীয় ডেটা বলে মনে হচ্ছে।

Answer 12

শুধু এটি ঠিক করুন।

আমি ঠিক এই দেখেছি। একটি থ্রেড একটি সার্ভারে একটি নেটওয়ার্ক অনুরোধ করতে পরিচালিত করে যা একটি জটিল ডাটাবেস অনুসন্ধান করে এবং অন্য থ্রেডের পরবর্তী লাইনে যাওয়ার আগে প্রতিক্রিয়া জানায়। এটা হয়।

কিছু গ্রাহক কোথাও কোথাও কোনও দিন এমন কিছু চালানোর সিদ্ধান্ত নেবেন যা ধীরে ধীরে থ্রেডটি চালিয়ে যাওয়ার সময় "দ্রুত" থ্রেডের জন্য সমস্ত সিপিইউ সময়কে হাগ করে, এবং আপনি দুঃখিত হবেন :)

Answer 13

যদি আপনি একটি অসম্ভব রেস শর্তটি স্বীকৃত হন তবে কমপক্ষে কোডটিতে এটি নথি করুন!

সম্পাদনা: আমার যুক্ত করা উচিত যে আমি যদি সম্ভব হয় তবে এটি ঠিক করেছি, তবে উপরের লেখার সময় অন্য কোনও উত্তর স্পষ্টভাবে বলেছিল না যে কোডটিতে সমস্যাটি ন্যূনতমভাবে নথিভুক্ত করুন।

Comments

হ্যাঁ, এবং অন্তত চেষ্টা করুন এবং এটি সনাক্ত করুন এবং যদি এটি ঘটে তবে লগইন করুন। আইএমএইচও প্রতিটি ত্রুটি এড়ানোর জন্য এটি পুরোপুরি ঠিক আছে। তবে কমপক্ষে কাউকে জানতে দিন যে এটি ঘটেছে, এবং আপনার অনুমান যে এটি বিপথগামী হয়নি।

— স্টিভ বেনেট

Answer 14

আমি মনে করি যে আপনি যদি ইতিমধ্যে জানেন যে কীভাবে এবং কেন এটি হতে পারে তবে এটির সাথে এটিরও মোকাবিলা করা যেতে পারে। এটি যদি প্রচুর পরিমাণে সংস্থান গ্রহণ না করে।

Answer 15

এটি সমস্ত কোনও জাতির শর্তের পরিণতি কী তার উপর নির্ভর করে। আমি মনে করি আপনার প্রশ্নের উত্তর দেওয়া লোকেরা তাদের কাজের লাইনের জন্য সঠিক। খনি রাউটার কনফিগারেশন ইঞ্জিন। আমার জন্য, বর্ণের পরিস্থিতি হয় সিস্টেমগুলিকে স্থির করে তোলে, দুর্নীতিগ্রস্থ বা অ-কনফিগার করা হয়েছে যদিও এটি বলেছিল এটি সফল। আমি রাউটারে সর্বদা সেমফোরস ব্যবহার করি যাতে আমাকে হাত দিয়ে কোনও জিনিস পরিষ্কার না করতে হয়।

আমি মনে করি আমার জিইউআই কোডের কিছু এখনও রেস শর্তগুলির জন্য এমনভাবে প্রবণ যে কোনও ব্যবহারকারীর একটি ত্রুটি দেওয়া যেতে পারে কারণ একটি রেসের শর্ত ঘটেছে, তবে ডেটা দুর্নীতি বা দুর্ব্যবহারের সম্ভাবনা থাকলে আমার এ জাতীয় কোনও সম্ভাবনা থাকবে না would যেমন ইভেন্টের পরে আবেদন।

Answer 16

আনন্দের সাথে যথেষ্ট, আমি সম্প্রতি এই সমস্যার মুখোমুখি হয়েছি। আমি বুঝতে পারি না যে আমার পরিস্থিতিতে একটি দৌড়ের অবস্থা সম্ভব ছিল। মাল্টি-কোর প্রসেসরগুলি আদর্শ হয়ে উঠলে কেবল রেসের শর্তটি নিজেকে উপস্থাপন করেছিল।

দৃশ্যটি মোটামুটি এরকম ছিল। একটি ডিভাইস ড্রাইভার এই সফ্টওয়্যারটি পরিচালনা করার জন্য ইভেন্ট উত্থাপন করেছিল। ডিভাইসে সময়সীমা রোধ করতে যত তাড়াতাড়ি সম্ভব নিয়ন্ত্রণকে ডিভাইস ড্রাইভারের কাছে ফিরে আসতে হয়েছিল। এটি নিশ্চিত করার জন্য, ইভেন্টটি পৃথক থ্রেডে রেকর্ড করা এবং সারিবদ্ধ করা হয়েছিল।

Receive event from device:
{
    Record event details.
    Enqueue event in the queuing thread.
    Acknowledge the event.
}

Queueing thread receives an event:
{
    Retrieve event details.
    Process event.
    Send next command to device.
}

এটি বছরের পর বছর ধরে কাজ করে। তারপরে হঠাৎ এটি নির্দিষ্ট কনফিগারেশনে ব্যর্থ হবে। দেখা যাচ্ছে যে একক প্রসেসরের সময় ভাগ না করে কুইউন্ডিং থ্রেডটি এখন ইভেন্ট হ্যান্ডলিং থ্রেডের সমান্তরালভাবে চলছিল। ইভেন্টটি স্বীকৃত হওয়ার আগে এটি ডিভাইসে পরবর্তী কমান্ডটি প্রেরণ করতে সক্ষম হয়েছিল, যার ফলে একটি ক্রম-বহির্মুখের ত্রুটি হয়েছিল।

এটি কেবল একটি কনফিগারেশনে একজন গ্রাহককে প্রভাবিত করেছে, আমি লজ্জার Thread.Sleep(1000)সাথে সমস্যাটি যেখানে রেখেছিলাম সেখানে রেখেছি । তখন থেকে কোনও সমস্যা হয়নি।