Споделени ресурси, конфликти, споделен достъп - 1

„Здравей, Амиго! Искам да ти разкажа за споделянето на ресурси. В различни теми, естествено.

„Продължавам да говоря за проблемите, които се случват при работа с множество нишки и How да ги разрешим. Това не означава, че използването на нишки е лошо. Нишките са много мощен инструмент. Всъщност те ви позволяват да направите програмата си по-бърза и дори по-надеждна. Колкото по-сложна е една програма, толкова повече нишки и различни независими части има."

"Разделянето на програма на независими (слабо свързани) части е много полезно."

„Представете си, че вашата програма е вътрешно разделена на 100 нишки. Но имате само двуядрен процесор. Това означава, че средно 50 нишки ще бъдат изпълнени на всяко ядро.“

„Ако имате нужда да увеличите производителността на програмата, просто купувате двупроцесорен сървър и няколко сладки процесора за него. Това може да ви осигури до 32 ядра, което води до 2-20 пъти увеличение на производителността. В зависимост от броя на наистина независими части, на които е разделен."

"Това е една от причините Java да доминира в корпоративното развитие. Ако една компания има сложна вътрешна програма, написана от 20 разработчици, тогава е много по-евтино да закупите друг сървър, отколкото да удвоите производителността на програмата чрез оптимизация."

— Значи за това става въпрос.

"Но! Всеки път, когато разработчик реши да използва друга нишка, той решава един проблем и създава две. Все повече и повече нишки няма безкрайно да увеличат производителността на програмата."

"Първо, всяка програма има работа, която не може да бъде разделена и да работи паралелно на различни нишки. Второ, всички нишки се изпълняват на един и същ процесор. Колкото повече нишки имате, толкова по-бавно работи всяка."

„И най-важното е, че нишките често използват едни и същи обекти (обикновено наричани „споделени ресурси“).“

"Например нишка иска да запази информация за работата, която е завършила във файл. Ако има няколко такива нишки и те искат да запишат информация в един и същи файл, те ще си пречат. За да се предотврати превръщането на file в объркана бъркотия, достъпът до file е ограничен, т.е. докато една нишка използва file, други чакат."

„Да, спомням си. Вие правите това, като използвате ключовата дума synchronized .“

"Абсолютно вярно."

„Ами ако нишките пишат в различни файлове?“

"Формално това са различни обекти, но вероятно са на един и същ твърд диск."

„И така, наистина ли е възможно да паралелизираме нещо вътре в процесора?“

„Технически да, но веднага щом вашата нишка се нуждае от нещо освен данните, които има, това нещо може вече да е заето от друга нишка – и вашата нишка ще трябва да изчака.“

"Е, Howво трябва да направя тогава? Как да разбера дали трябва да правя много теми or не?"

„Това се определя директно от архитектурата на вашата програма. Всеки проект има свой собствен „архитект“, който познава всички „ресурси“, използвани в програмата, знае техните ограничения и колко добре/зле са паралелизирани.“

— А ако не знам?

"Има две възможности:"

а) работа под надзора на някой, който го прави

б) вземете някои бучки, за да го разберете сами

"Аз съм робот: не получавам бучки - само вдлъбнатини."

— Е, тогава вземете малко вдлъбнатини.

„Разбирам. Благодаря. Ти изясни някои неща, за които вече бях започнал да се чудя.“