মাল্টিথ্রিড এবং মাল্টিপ্রসেসর প্রোগ্রামিংয়ের জন্য কি অবজ্ঞাত পদ্ধতি রয়েছে যা আমার আর ব্যবহার করা উচিত নয়?


36

ফরটেন এবং বেসিকের প্রথম দিনগুলিতে, সমস্ত প্রোগ্রামগুলি GOTO বিবৃতি সহ লেখা ছিল। ফলাফলটি স্প্যাগেটি কোড ছিল এবং সমাধানটি ছিল কাঠামোগত প্রোগ্রামিং।

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

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

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

উদাহরণস্বরূপ, মাল্টিকোর প্রসেসরের সাহায্যে বহুবিধ প্রোগ্রামিংয়ের জন্য সিস্টেমের একটি নির্দিষ্ট উদাহরণ হ'ল ওপেনএমপি। এটি সেমফোরগুলি ব্যবহার না করে নীচের মতো একটি সমালোচনামূলক অঞ্চলকে উপস্থাপন করে যা পরিবেশে অন্তর্ভুক্ত বলে মনে হয় না।

th_id = omp_get_thread_num();
#pragma omp critical
{
  cout << "Hello World from thread " << th_id << '\n';
}

এই উদাহরণটি: http://en.wikedia.org/wiki/OpenMP থেকে প্রাপ্ত একটি উদ্ধৃতি

বিকল্পভাবে, ফাংশন ওয়েট () এবং সিগন্যাল () সহ সমুদ্রের ক্ষেত্রগুলি ব্যবহার করে একে অপরের কাছ থেকে থ্রেডগুলির অনুরূপ সুরক্ষা এ জাতীয় দেখতে পাওয়া যেতে পারে:

wait(sem);
th_id = get_thread_num();
cout << "Hello World from thread " << th_id << '\n';
signal(sem);

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

ওপেনএমপি-এর মতো এই সিস্টেমগুলি কি সেমোফোরগুলির সাথে সমস্যাগুলি দূর করে?
তারা কি সমস্যা অন্য কোথাও সরিয়ে নিয়েছে?
আর আমি সেমোফোরগুলি ব্যবহার না করার জন্য অ্যালগোরিদম ব্যবহার করে কীভাবে আমার প্রিয় সেম্যাফোরটি রূপান্তর করব?


আপনি ঠিক কি সম্পর্কে কথা বলছেন? তুমি কি দেখেছিলে?
এসভিক

4
অভদ্র হওয়ার অর্থ নয়, তবে আপনি প্রথম তিনটি অনুচ্ছেদটি মুছে ফেলতে পারতেন। তারা আপনার প্রশ্নটি সত্যই বহন করে না এবং তারা তাদের সিদ্ধান্তে অতিরঞ্জিত হয় এবং কেবল প্রচুর যুক্তি উত্পন্ন করবে।
dbracey

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

উত্তর:


15

একযোগে প্রোগ্রামিং কৌশল এবং অনুশীলন রয়েছে যেগুলি আর ব্যবহার করা উচিত নয়? আমি হ্যাঁ বলব ।

একটি প্রাথমিক যুগ্ম প্রোগ্রামিং প্রযুক্তি যা আজকাল বিরল বলে মনে হচ্ছে হ'ল বিঘ্নিত চালিত প্রোগ্রামিং। ১৯ UN০ এর দশকে ইউএনআইএক্স এভাবেই কাজ করেছিল। ইউএনআইএক্স বা ল্যাক্স ইউএনএক্স অপারেটিং সিস্টেমের নকশায় সিংহদের মন্তব্য দেখুন । সংক্ষেপে, কৌশলটি হ'ল কোনও ডেটা স্ট্রাকচারের সাথে সামঞ্জস্য করার সময় অস্থায়ীভাবে বাধা স্থগিত করা এবং তারপরে বাধাগুলি পুনরুদ্ধার করা। বাসদ SPL (9) man পৃষ্ঠাকোডিংয়ের এই স্টাইলের উদাহরণ রয়েছে। মনে রাখবেন যে বাধাগুলি হার্ডওয়্যার-ভিত্তিক, এবং কোডটি হার্ডওয়্যার বিঘ্নিত হওয়ার ধরণের এবং সেই হার্ডওয়্যারের সাথে সম্পর্কিত ডেটা স্ট্রাকচারের মধ্যে একটি অন্তর্নিহিত সম্পর্ককে সূচিত করে। উদাহরণস্বরূপ, কোড যা ডিস্ক আই / ও বাফারগুলি পরিচালনা করে those বাফারগুলির সাথে কাজ করার সময় ডিস্ক নিয়ন্ত্রণকারী হার্ডওয়্যার থেকে বিঘ্ন স্থগিত করা উচিত।

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

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

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

এখানে অতিরিক্ত লাইব্রেরি নির্মাণ রয়েছে যেমন জাভা java.util.concurrentপ্যাকেজের মতো, এতে প্রচুর পরিমাণে সমবর্তী ডেটা স্ট্রাকচার এবং থ্রেড পুলিং কনস্ট্রাক্ট রয়েছে includes এগুলি অতিরিক্ত কৌশলগুলির সাথে একত্রিত করা যেতে পারে যেমন থ্রেড আবদ্ধকরণ এবং কার্যকর অপরিবর্তনীয়তা। গোয়েজ এট দ্বারা অনুশীলনে জাভা কনকুরেন্সি দেখুন । অল। আরও আলোচনার জন্য। দুর্ভাগ্যক্রমে, অনেক প্রোগ্রামার এখনও লক এবং শর্তগুলির সাথে তাদের নিজস্ব ডেটা স্ট্রাকচারগুলি ঘূর্ণন করছে, যখন তাদের সত্যিকার অর্থে কনকন্টারহ্যাশম্যাপের মতো এমন কিছু ব্যবহার করা উচিত যেখানে ভারী উত্তোলন ইতিমধ্যে গ্রন্থাগারের লেখকরা করেছেন।

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

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

সম্পাদনা: এখানে নির্দিষ্ট প্রশ্নের শেষে আমার প্রতিক্রিয়া।

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

আপনার যদি সমান্তরাল আলগরিদম সমান্তরাল ব্যবহার করে থাকে তবে আমি এটি রূপান্তর করার কোনও সাধারণ কৌশল জানি না। আপনি এটিকে অবজেক্টগুলিতে রিফ্যাক্টর করতে সক্ষম করতে পারেন এবং তার চারপাশে কিছু বিমূর্ততা তৈরি করতে পারেন। তবে আপনি যদি বার্তা পাঠানোর মতো কিছু ব্যবহার করতে চান তবে আমার মনে হয় আপনার পুরো সমস্যাটি পুনরায় স্বীকৃতি দেওয়া দরকার।


ধন্যবাদ, এটি দুর্দান্ত তথ্য। আমি রেফারেন্সগুলি সন্ধান করব এবং আপনি যে ধারণাগুলি আমার কাছে নতুন mention
বিকাশকারী

Java.util.concurrent জন্য +1 এবং মন্তব্যে একমত হয়েছেন - এটি জেডিকে ২.৩০ সাল থেকে এবং এটি ব্যবহার করা আমি খুব কমই দেখি।
মেবাআলোন

1
আমি আশা করি আপনি হাইলাইট করেছেন যে ইতিমধ্যে বিদ্যমান থাকলে নিজের কাঠামো রোল না করা কতটা গুরুত্বপূর্ণ is অনেকগুলি,
এতগুলি

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

@ জোশপিয়াস অবশ্যই সেমোফোরগুলি হার্ডওয়্যার কনস্ট্রাক্ট ব্যবহার করে প্রয়োগ করা হয় তবে এগুলি একটি বিমূর্ততা যা কোনও নির্দিষ্ট হার্ডওয়্যার নির্মাণ যেমন সিএএস, টেস্ট-অ্যান্ড-সেট, সিএমপিএক্সচং ইত্যাদির থেকে পৃথক
স্টুয়ার্ট মার্কস

28

প্রশ্নের উত্তর দাও

সাধারণ sensক্যমত্য ভাগ করে নেওয়া হয় পরিবর্তনযোগ্য রাষ্ট্রটি খারাপ is, এবং অস্থাবর রাষ্ট্র ভাল ™, যা কার্যকরী ভাষা এবং অপরিহার্য ভাষাগুলির দ্বারাও বারবার সঠিক এবং সত্য প্রমাণিত ven

সমস্যাটি মূলধারার অপরিহার্য ভাষাগুলি কেবল এইভাবে কাজ করার জন্য ডিজাইন করা হয়নি, রাতারাতি এই ভাষাগুলির জন্য জিনিসগুলি বদলাবে না। এখানেই তুলনা GOTOত্রুটিযুক্ত। অপরিবর্তনীয় স্থিতি এবং বার্তা উত্তরণ একটি দুর্দান্ত সমাধান তবে এটি কোনও ক্ষুদ্র রোগ নয় isn't

ত্রুটিযুক্ত প্রতিদ্বন্দ্বিতা

এই প্রশ্নটি ত্রুটিযুক্ত ভিত্তিতে তুলনার ভিত্তিতে তৈরি; যে GOTOপ্রকৃত সমস্যা ছিল এবং সর্বজনীন করে কিছু কিভাবে অবচিত করা হয়েছিল ভাষা পরিকল্পক ও সফটওয়্যার ইঞ্জিনিয়ারিং ইউনিয়ন Intergalatic ইউনিভার্সাল বোর্ড ©! GOTOমেকানিজম ছাড়া এএসএম মোটেও কাজ করবে না। এই ধারণাটির সাথে একই যে কাঁচা পয়েন্টার হ'ল সি বা সি ++ এর সমস্যা এবং কিছু স্মার্ট পয়েন্টার কীভাবে একটি প্যানাসিয়া, তা নয়।

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

শিক্ষা হ'ল প্যানাসিয়া

ইডিয়ট প্রোগ্রামাররা কি ছিল deprecated , প্রতিটি জনপ্রিয় ভাষায় এখনও GOTOপ্রত্যক্ষ বা অপ্রত্যক্ষভাবে কন্সট্রাক্ট থাকে এবং এটি এমন একটি ভাষা best practiceযখন প্রতিটি ভাষায় এই ধরণের কনস্ট্রাক্টস সঠিকভাবে ব্যবহৃত হয়।

উদাহরণ: জাভার লেবেল রয়েছে এবং try/catch/finallyউভয়ই সরাসরি GOTOবিবৃতি হিসাবে কাজ করে ।

বেশিরভাগ জাভা প্রোগ্রামার যার সাথে আমি কথা বলি তা এমনকি তাদের চোখের মতো দেখতে কোনও জম্বি দিয়ে immutableপুনরাবৃত্তি the String class is immutableকরার বাইরে এর অর্থ কী তাও জানেন না । কোনও ক্লাস তৈরির জন্য কীওয়ার্ডটি সঠিকভাবে ব্যবহার করতেfinal হবে তা তারা অবশ্যই জানে না immutable। সুতরাং আমি দৃ sure়ভাবে নিশ্চিত যে অপরিবর্তনীয় বার্তা ব্যবহার করে মেসেজিং পাস করা এত দুর্দান্ত কেন এবং ভাগ করে নেওয়া মিউটেজের অবস্থা এত দুর্দান্ত কেন তা তাদের কোনও ধারণা নেই ।


3
+1 দুর্দান্ত উত্তর, পরিষ্কারভাবে লিখিত এবং পরিবর্তনীয় স্থিতির অন্তর্নিহিত প্যাটার্নটিকে পিনপয়েন্ট করছে। আইইউবিএলডিএসইউ একটি মেম হওয়া উচিত :)
ডিব্বেকে

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

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

2
শিখা যুদ্ধ শুরু করা আমার উদ্দেশ্য ছিল না। যতক্ষণ পর্যন্ত জারোদ আমার মন্তব্যে প্রতিক্রিয়া জানাল না, ভেবেছিল যে GOTO বিতর্কিত নয় এবং একটি উপমা অনুসারে ভালভাবে কাজ করবে। আমি যখন প্রশ্নটি লিখেছিলাম তখন তা আমার কাছে ঘটেনি, তবে ডিজটস্রা জিওটিও এবং সেমোফোর উভয় ক্ষেত্রেই গ্রাউন্ড শূন্য ছিল। এডজার ডিজকস্ট্রা আমার কাছে এক বিশাল দৈত্যের মতো বলে মনে হয় এবং সেমফোরস আবিষ্কার (১৯65৫) এবং গোটস সম্পর্কে প্রাথমিকভাবে (১৯68৮) পণ্ডিত কাজের কৃতিত্ব পেয়েছিল। ডিজকস্ট্রার অ্যাডভোকেসির পদ্ধতিটি প্রায়শই চটচটে এবং দ্বন্দ্বপূর্ণ ছিল। বিতর্ক / দ্বন্দ্ব তার পক্ষে কাজ করেছিল, তবে আমি কেবলমাত্র সেমোফোরগুলির সম্ভাব্য বিকল্পগুলি সম্পর্কে ধারণা চাই।
বিকাশকারী

1
অনেক প্রোগ্রামের এমন জিনিসগুলির মডেল করার কথা রয়েছে যা আসল বিশ্বে পরিবর্তনীয়। যদি সকাল 5:37 এ অবজেক্ট # 451 সেই মুহুর্তে (বাস্তব সময়ে 5:37) রিয়েল-ওয়ার্ল্ডের কোনও কিছুর অবস্থান ধরে রাখে এবং পরবর্তী সময়ে বাস্তব-জগতের জিনিসের অবস্থা পরিবর্তিত হয়, তবে বস্তুর প্রতিনিধিত্বকারী উভয়ের পরিচয়ের পক্ষে এটি সম্ভব আসল-বিশ্বের জিনিসের স্থাবর হতে হবে (যেমন জিনিসটি সর্বদা # 451 অবজেক্ট দ্বারা প্রতিনিধিত্ব করা হবে) বা অবজেক্টযোগ্য # 451 অবজেক্টের জন্য, তবে উভয়ই নয়। বেশিরভাগ ক্ষেত্রে, পরিচয়টি অপরিবর্তনীয় হতে পারলে অপরিবর্তনীয় # 451 অবজেক্ট থাকার চেয়ে আরও বেশি সহায়ক হবে।
সুপারক্যাট

27

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

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

আমি যে অন্যান্য মডেল সম্পর্কে অবগত রয়েছি তা হ'ল লক এবং থ্রেড ব্যবহার করে না হ'ল ফিউচারগুলি ব্যবহার করা যা সত্যই অ্যাসিঙ্ক প্রোগ্রামিংয়ের অন্য একটি রূপ।

আমি নিশ্চিত নই যে এই প্রযুক্তিটির কতটা সি ++ তে উপলব্ধ but


নতুন শব্দ "লোমশ বিবরণ" এর জন্য +1। LOL মানুষ। আমি এই নতুন শব্দটিতে হাসি থামাতে পারি না। আমার ধারণা আমি এখন থেকে "লোমশ কোড" ব্যবহার করব।
সা Saeedদ নেমতি

1
@ সাeedদ: আমি আগেই এই অভিব্যক্তিটি শুনেছি, এটি এতটা অস্বাভাবিক নয়। আমি সম্মত হই যদিও এটি মজার :-)
ক্যামেরন

1
ভাল উত্তর. । নেট সি এল এলির মনে হয় সিগন্যালিং (লকিংয়ের বিপরীতে) এর পক্ষেও সমর্থন আছে তবে আমি এখনও এমন একটি উদাহরণ দেখতে পাইনি যেখানে এটি লকিংয়ের পুরোপুরি প্রতিস্থাপন করেছিল। আমি নিশ্চিত না যে অ্যাসিঙ্ক গণনা করে। আপনি যদি জাভাস্ক্রিপ্ট / নোডজেসের মতো প্ল্যাটফর্মগুলির বিষয়ে কথা বলছেন তবে এগুলি প্রকৃতপক্ষে একক থ্রেডযুক্ত এবং উচ্চ আইও লোডগুলিতে কেবল ভাল because সিপিইউ নিবিড় লোডগুলিতে অ্যাসিঙ্ক প্রোগ্রামিংটি ব্যবহার করার সামান্য / কোনও লাভ নেই।
ইভান প্লেইস

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

1
আমি লক ফ্রি যুক্ত করব এবং সেই তালিকায় ফ্রি ডেটা স্ট্রাকচার অপেক্ষা করব।
স্টোনমেটাল

3

আমি মনে করি এটি বেশিরভাগ বিমূর্ততার স্তর সম্পর্কে। বেশিরভাগ প্রোগ্রামিংয়ে বেশিরভাগ ক্ষেত্রেই কিছু বিশদ এমনভাবে সুরক্ষিত বা আরও বেশি পঠনযোগ্য বা এর মতো কিছু থেকে দূরে রাখা কার্যকর।

এটি নিয়ন্ত্রণ কাঠামোর ক্ষেত্রে প্রযোজ্য: ifগুলি, forগুলি এবং এমনকি try- catchব্লকগুলি gotoএস এর উপর কেবল বিমূর্ততা । এই বিমূর্ততা প্রায় সর্বদা দরকারী, কারণ তারা আপনার কোডটি আরও পঠনযোগ্য করে তোলে। তবে এমন কিছু ক্ষেত্রে রয়েছে যখন আপনার এখনও ব্যবহার করতে হবেgoto (যেমন আপনি যদি হাতের দ্বারা সমাবেশ লিখছেন)।

এটি মেমরি পরিচালনার ক্ষেত্রেও প্রযোজ্য: সি ++ স্মার্ট পয়েন্টার এবং জিসি কাঁচা পয়েন্টার এবং ম্যানুয়াল মেমোরি ডি-/ বরাদ্দের উপর বিমূর্ততা। এবং কখনও কখনও, এই বিমূর্ততা যথাযথ হয় না, যেমন যখন আপনার সত্যিকার অর্থে সর্বাধিক কর্মক্ষমতা প্রয়োজন।

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

আপনার কী কী সরঞ্জাম উপলব্ধ রয়েছে এবং সেগুলির সুবিধা এবং অসুবিধাগুলি কী তা আপনার জানা উচিত। তারপরে আপনি আপনার টাস্কের জন্য সঠিক বিমূর্ততা চয়ন করতে পারেন (যদি থাকে)। উচ্চ স্তরের বিমূর্ততা নিম্ন স্তরের অবনতি ঘটায় না, এমন কিছু ক্ষেত্রে সবসময় দেখা যায় যেখানে বিমূর্তি যথাযথ নয় এবং সেরা পছন্দটি হল "পুরানো উপায়" ব্যবহার করা।


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

2

হ্যাঁ, তবে আপনি তাদের মধ্যে কিছু চালানোর সম্ভাবনা নেই।

পুরানো দিনগুলিতে, ব্লকিং পদ্ধতিগুলি (বাধা সিঙ্ক্রোনাইজেশন) ব্যবহার করা সাধারণ ছিল কারণ ভাল মুটেক্সগুলি লিখতে সঠিকভাবে কাজ করা শক্ত ছিল। সাম্প্রতিক হিসাবে আধুনিক জিনিসপত্রের লাইব্রেরিগুলি আপনাকে সামঞ্জস্য এবং আন্তঃ প্রক্রিয়া সমন্বয়ের জন্য সরঞ্জামগুলির সেটকে আরও সমৃদ্ধ, এবং পুরোপুরি পরীক্ষিত, সরঞ্জামগুলি দেয় এমন হিসাবে আপনি এখনও এগুলির চিহ্নগুলি দেখতে পাচ্ছেন।

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

সুতরাং সম্ভবত অবহেলিত অনুশীলনটি আধুনিক, ভাল-পরীক্ষিত লাইব্রেরিগুলি না ব্যবহার করে নিজেই সমঝোতা কোড লিখছে।


ধন্যবাদ। মনে হচ্ছে সমবর্তী প্রোগ্রামিং ব্যবহারের দুর্দান্ত সম্ভাবনা রয়েছে তবে শৃঙ্খলাবদ্ধভাবে ব্যবহার না করা হলে এটি প্যান্ডোরার বাক্স হতে পারে।
বিকাশকারী

2

অ্যাপলের গ্র্যান্ড সেন্ট্রাল ডিসপ্যাচ হ'ল মার্জিত বিমূর্ততা যা চুক্তির সাথে আমার চিন্তাভাবনা পরিবর্তন করেছে। সারিগুলির উপর এটির ফোকাস আমার নম্র অভিজ্ঞতায় অ্যাসিঙ্ক্রোনাস যুক্তিকে বাস্তবের আকারকে সহজতর করে তোলে।

আমি যখন উপলব্ধ পরিবেশগুলিতে প্রোগ্রাম করি তখন এটি আমার বেশিরভাগ থ্রেড, লক এবং আন্তঃ-থ্রেড যোগাযোগের জায়গা করে নিয়েছিল।


1

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

এ্যাসিঙ্ক বা টাস্ক-ভিত্তিক (উদাহরণস্বরূপ গ্র্যান্ড সেন্ট্রাল ডিসপ্যাচ, বা ইন্টেলের টিবিবি) ফ্রেমওয়ার্কগুলি আরও জনপ্রিয় হওয়ার কারণ এটি, তারা একটি সময়ে কোড 1 টাস্ক চালায়, পরেরটিতে যাওয়ার আগে এটি সম্পন্ন করে - তবে আপনাকে অবশ্যই প্রতিটি কোডটি কোড করতে হবে আপনি ডিজাইনটি স্ক্রু করতে না চাইলে প্রতিটি কাজ অল্প সময় নিতে হবে (যেমন আপনার সমান্তরাল কাজগুলি সত্যই সারিবদ্ধ)। সিপিইউ-নিবিড় কাজগুলি সমস্ত কার্য একক থ্রেড প্রসেসিংয়ের পরিবর্তে বিকল্প সিপিইউ কোরকে দেওয়া হয়। সত্যিকার অর্থে কোনও মাল্টি-থ্রেড প্রসেসিং চলছে না তা পরিচালনা করাও সহজ।


দুর্দান্ত, অ্যাপল এবং ইন্টেল প্রযুক্তির রেফারেন্সের জন্য ধন্যবাদ। আপনার উত্তরটি মূল সখ্যতায় থ্রেড পরিচালনার চ্যালেঞ্জগুলি নির্দেশ করছে? কিছু ক্যাশে পারফরম্যান্সের সমস্যাগুলি সহজ করা হয়েছে কারণ মাল্টিকোর প্রসেসরগুলি প্রতি कोर এল 1 ক্যাশে পুনরাবৃত্তি করতে পারে? উদাহরণস্বরূপ: software.intel.com/en-us/articles/… আরও ক্যাশে হিট সহ চারটি কোরের জন্য উচ্চ গতির ক্যাশে একই ডেটাতে আরও ক্যাশে মিস হওয়া একটি কোর হিসাবে তত দ্রুত 4x এর বেশি হতে পারে। ম্যাট্রিক্সের গুণন করতে পারে। 4 টি কোরে 32 টি থ্রেডের এলোমেলো সময়সূচী করতে পারে না। আসুন অ্যাফিনিটি ব্যবহার করুন এবং 32 টি কোর পাবেন।
বিকাশকারী

আসলে একই সমস্যা না হলেও - মূল সখ্যতা কেবল সেই সমস্যাটিকে বোঝায় যেখানে কোনও কাজটি কোর থেকে অন্য দিকে অগ্রসর হয়। এটি একই সমস্যা যদি কোনও কাজ বাধাগ্রস্ত হয়, নতুন সাথে প্রতিস্থাপিত হয়, তবে মূল কাজটি একই কোরটিতে অবিরত থাকবে। ইন্টেলের বক্তব্য সেখানে: ক্যাশে হিট = দ্রুত, ক্যাশে মিস = ধীর, করের সংখ্যা নির্বিশেষে। আমি মনে করি তারা এএমডি এর চেয়ে তাদের চিপগুলি কিনতে আপনাকে প্ররোচিত করার চেষ্টা করছেন :)
gbjbaanb
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.