Разговор со корисник:Todevska

Добре дојдовте!

Здраво, Todevska, и добре дојдовте на Википедија! Благодарам за Вашите придонеси. Се надевам дека Ви се допадна проектов и дека одлучивте да останете. Еве неколку страници кои можеби ќе Ви се најдат како корисни:

• Петте столба на Википедија
• Почетен курс
• Како да уредувате страници
• Како да создадете статија

Се надевам дека ќе уживате во уредувањето овде и во тоа што сте Википедијанец! Ве молам потпишувајте ги Вашите пораки на разговорните страници со внесување на четири тилди (~~~~); ова автоматски ќе го внесе Вашето корисничко име и датумот. Ако Ви треба помош, погледајте ја страницата Википедија:Прашања, прашајте ме мене на мојата разговорна страница, или поставете го прашањето на оваа страница, а потоа ставете {{помош}} пред прашањето. Уште еднаш, добре дојдовте! --Brest-bot (разговор) 14:24, 4 јануари 2011 (CET)

Здраво

Јас ти помагам, ти средувам текстот. Ако сакаш, напиши што мислиш, па јас ќе средам отпосле. Поз--Никола ^{Стоіаноски} 15:31, 12 јануари 2011 (CET)

Ај ќе те научам, за Скајп е лесно ќе те додадам. Ако сакаш некому да му пишеш, ќе одиш кај него на страната за разговор и еве како ќе го најдеш. На пример, мене ќе ме најдеш ако во делот Пребарај (одма од страна) пишеш Корисник:MacedonianBoy (наместо MacedonianBoy можеш кое било корисничко име да пишеш) и ќе ти се отвори мојата страница. Најгоре пишува Разговор, кликни на тоа и ќе ти се отвори мојот разговор. Стисни на уреди и оди најдолу и почни да пишуваш порака. Пред пораката стави наслов и насловот во овие знаци == == за да излезе како секција во статија. И толку. Твојот разговор ќе го најдеш ако погледнеш најгоре на прозорот и има Мој разговор, кликни на него и ќе одиш кај твојот разговор. Поз--Никола ^{Стоіаноски} 15:40, 12 јануари 2011 (CET)

Не, јас сум еден од администраторите на Википедија. Видов дека пиша нова статија и реков да ти помогнам при средување. --Никола ^{Стоіаноски} 15:47, 12 јануари 2011 (CET)

Супер, немај гајле. Кога ќе завршиш пиши ми па јас ќе средам од технички аспект. Поздрав и успешна работа.--Никола ^{Стоіаноски} 15:51, 12 јануари 2011 (CET)

Ја вратив статијата како што ти беше, пола преведена, пола на англиски. На ова мислеше?--Никола ^{Стоіаноски} 15:55, 12 јануари 2011 (CET)

IPv6 беше стара статија на Википедија, ја уредил еден од администраторите, уште пред некое време.--Никола ^{Стоіаноски} 15:58, 12 јануари 2011 (CET)

Да, ако имаше некој непознат збор остави го во статијата па јас ќе видам. А ако сакаш да ти биде сè на време, можеш да провериш и со овој речник, но ти како сакаш.--Никола ^{Стоіаноски} 16:00, 12 јануари 2011 (CET)

ОК, бркај работа, кога ќе завршиш тогаш пиши ми. Ќе ја проврам статијата кога ќе биде. Поздрав --Никола ^{Стоіаноски} 16:05, 12 јануари 2011 (CET)

Грешка во заградите и стрелките околу зборчињата nowiki и code. Тие се кодови на Википедија и ако се избрише барем една црта се зезнува текстот. Но го средив. --Никола ^{Стоіаноски} 16:14, 12 јануари 2011 (CET)

Готово, ја средив статијата од технички и правописен аспект. Има доста англицизми низ статијата, а на нашата Википедија имаме тенденција да користиме чисти македонски зборови. Но поради природата на статијата, допуштив да се користат некои анлицизми (како порт, пин и слично), бидејќи некои тешко можат да се преведат со македонски зборови. Сепак супер статија. Поз--Никола ^{Стоіаноски} 21:21, 12 јануари 2011 (CET)

Награда

За вложениот труд во збогатувањето на содржините на Википедија на македонски јазик.

од Kiril Simeonovski (разговор)

Ја заслуживте оваа награда, која претставува само знак на внимание и почит кон Вашите досегашни придонеси на Википедија на македнски јазик. Се надевам дека ќе продолжите со одличните придонеси и понатаму, а доколку имате потреба од помош, слободно обратете ми се на мојата корисничка страница. Поздрав и успешно уредување.--Kiril Simeonovski (разговор) 23:41, 12 јануари 2011 (CET)

Хелоу

Здраво и од мене. Ја проверив статијата и таа е одлична. Има само еден недостаток, а тоа е нема наводи или референци. Супер е средена, има обилни информации, ама пак ќе речам нема референци, а ако имаше, со мали корекции ќе можеше да биде избрана статија на Википедија. Поздрав и се најдобро, --Никола ^{Стоіаноски} 18:22, 15 јануари 2011 (CET)

Процеси и нишки Процес е инстанца на компјутерска програма, која се состои од една или повеќе нишки, кои се извршуваат секвенцијално од компјутерскиот систем. За да му се овозможи на кернелот да раководи со процесите, секој процес е претставен од процесен дескриптор кој содржи информација за моменталната состојба на процесот. Секој процес може да се најде во неколку состојби; моменталната состојба на процесот може да се дознае од процесниот дескриптор. Освен состојбата на процесот, процесниот дескриптор чува информации за PID бројот на процесот, односите родител-дете и др. За да се овозможи ефикасно пребарување низ процесите од даден тип, кернелот создава неколку листи на процеси. Постојат многу причини поради кои еден процес мора да чека за некој системски ресурс. Кернелот на Linux користи едноставна податочна структура, ред на чекање, за организација на процесите кои чекаат. Процесот 0 е предок на сите процеси, кој се создава во фазата на иницијализација на Linux. Нормалните процеси кај Linux се создаваат со помош на системскиот повик clone( ). Терминацијата на процесите може да биде нормална – по завршување на задачата што требало да ја извршат, и присилна.

Вовед

Поимот “процес” се користи често со неколку различни значења. Основната дефиниција на овој поим во врска со оперативните системи е: “Процес е инстанца на програма во извршување”. Процесот може да се смета како колекција на податочни структури кои целосно опишуваат до каде стигнало извршувањето на програмата. Процесите се како човечки суштества: тие се создаваат, имаат повеќе или помалку значаен живот, опционално генерираат еден или повеќе процеси-деца, и на крајот умираат. Постои разлика во тоа што секој процес има само еден родител. Од гледна точка на кернелот, целта на еден процес е да дејствува како ентитет на кој се алоцираат системските ресурси (процесорско време, меморија итн.). Кога еден процес е создаден, тој е скоро идентичен со неговиот родител. Тој добива (логичка) копија од адресниот простор на родителот и го извршува истиот код како родителот, почнувајќи од следната инструкција и следејќи го системскиот повик за креирање на процес. Иако родителот и детето можат да ги делат страниците кои го содржат програмскиот код (текст), тие имаат одделни копии на податоците (стекови и хип), така што промените на мемориската локација од страна на детето се невидливи за родителот, и обратно. Претходните кернели на Unix го користеле овој едноставен модел, но модерните Unix системи не го користат. Тие поддржуваат апликации со повеќе нишки (treads) – кориснички програми кои имаат многу релативно независни текови на извршувања кои делат големо количество на апликациски структури на податоци. Во таквите системи, еден процес е составен од повеќе нишки, од кои секоја претставува тек на извршување на процесот. Денес, најголем дел од апликациите со повеќе нишки се напишани со користење на стандардни сетови на библиотечни функции наречени pthreads (POSIX threads) библиотеки. Постарите верзии на кернелот на Linux не нуделе поддршка за апликациите со повеќе нишки. Од гледна точка на кернелот, апликација со повеќе нишки не претставува ништо друго освен нормален процес. Тековите на извршувања на апликациите со повеќе нишки се креирани и управувани целосно во кориснички мод, обично со средствата на POSIX-компатибилна pthread библиотека. Како и да е, таквата имплементација на апликациите со повеќе нишки не е многу задоволителна. На пример; да претпоставиме дека програма за шах користи две нишки: едната ја контролира графичката шаховска табла, која чека на потезите на играчот и ги покажува потезите на компјутерот, додека другата нишка го планира следниот потег. Додека првата нишка чека на потегот на играчот, втората нишка треба да се извршува постојано, користејќи го времето на размислување на играчот. Сепак, ако програмата за шах е само еден процес, првата нишка не може едноставно да користи системски повик за блокирање чекајќи на акција на корисникот. Наместо тоа, првата нишка мора да користи софистицирани техники кои не користат блокирање за да се осигураат дека процесот ќе продолжи да се извршува. Linux користи lightweight процеси за да понуди поддршка за апликациите со повеќе нишки. Во основа, два lightweight процеси можат да делат некои ресурси, како адресниот простор, датотеки итн. Ако било кој од нив модифицира делив ресурс, другиот веднаш ја гледа промената. Секако дека двата процеса мора да се синхронизираат меѓусебно кога пристапуваат до заеднички ресурси. Ако се достапни lightweight процесите, недвосмислен начин да се имплементираат апликации со повеќе нишки е да се асоцира lightweight процес со секоја нишка. На овој начин, нишките може да пристапат до истата група на податочни структури на апликацијата едноставно со делење на истиот мемориски адресен простор, истата група на датотеки итн. во исто време. Два примера на POSIX-компатибилни pthread библиотеки кои ги користат lightweight процесите на Linux се LinuxThreads и неодамна пуштениот во употреба Next Generation Posix Threading Package (NGPT) на IBM.

Процесен дескриптор

За да управува со процеси, кернелот мора да има чиста слика за тоа што работи секој од процесите. Мора да го знае, на пример, приоритетот на процесот, дали се извршува во ЦПЕ или е блокиран од настан, кој адресен простор му е доделен итн. Ова е улога на процесниот дескриптор – task-struct тип на структура чии полиња ги содржат сите информации поврзани со одреден процес. Како репозиториум на толку многу информации, процесниот дескриптор е прилично комплексен. Како додаток на големиот број на полиња кои ги содржат атрибутите на процесите, процесниот дескриптор содржи и неколку покажувачи на други структури на податоци кои, пак,содржат покажувачи кон други структури.

Состојба на процес

Како што кажува името, полето за состојба на процесот кај процесниот дескриптор опишува што се случува со процесот во моментот. Полето се состои од низа од “знамиња” (flags), и секое од нив опишува една можна состојба на процесот. Во сегашната верзија на Linux овие состојби взаемно се исклучуваат, и оттаму само едно знаме на состојба е сетирано во еден момент. Можни состојби на процесот се: TASK_RUNNING Процесот се извршува во ЦПЕ или чека да биде извршен. TASK_INTERRUPTIBLE Процесот е суспендиран (се заспива) додека не се исполни некој услов. Појава на хардверски прекин, ослободување на ресурсот кој го чека процесот, или примање на сигнал се примери за услови кои може да го разбудат процесот (да ја постават неговата состојба на TASK RUNNING). TASK_UNINTERRUPTIBLE Исто како и претходната состојба, освен тоа што испраќањето на сигнал до заспаниот процес не ја менува состојбата. Оваа состојба на процесот ретко се користи. Сепак ова е корисно под одредени специфични услови во кои еден процес мора да чека додека дадениот настан се случи. На пример, оваа состојба може да биде искористена кога еден процес користи уред и соодветниот драјвер започнува со побарување за соодветниот хардверски уред. Драјверот за уредот не смее да биде прекинат додека побарувањето е завршено, инаку хардверскиот уред може да остане во недефинирана состојба. TASK_STOPPED Извршувањето на процесот е стопирано; еден процес влегува во оваа состојба по примање на SIGSTOP, SIGTSTP, SIGTTIN, или SIGTTOU сигнал. Кога еден процес е надгледуван од друг, секој сигнал може да го стави процесот во TASK_STOPPED состојба. TASK_ZOMBIE Извршувањето на процесот е прекинато, но процесот родител сè уште не издал системски повик за чекање, за да врати информација за убиениот процес. Пред да се издаде системскиот повик за чекање, кернелот не може да ги отфрли податоците кои се сместени во дескрипторот за убиениот процес затоа што можеби ќе му се потребни на родителот. Вредноста на полето на состојба обично сетирано со едноставно доделување. На пример: procdesc_ptr->state = TASK_RUNNING; Кернелот исто така ги користи set_task_state и set_current_state: тие ја поставуваат состојбата на дадениот прецес и на процесот што се извршува во моментот, соодветно. Уште повеќе, овие наредби даваат гаранција дека доделената операција не е измешана со други инструкции од компајлерот или контролната единица на ЦПЕ. Мешањето на редот на извршување на инструкциите понекогаш може да доведе до катастрофални последици.

Идентификација на процес

Како генерално правило, секој контекст на извршувањето кој може да биде координиран независно мора да има свој порцесен дескриптор, оттаму, дури и lightweight процесите, кои делат големо количество од нивните податочни структури, имаат сопствени структури task_struct. Строгата еден-на-еден кореспонденција помеѓу процесите и процесните дескриптори ја прават 32-битните адреси на процесниот дескриптор, корисно средство кое му помага на кернелот да ги идентификува процесите. Овие адреси се наведени како покажувачи на процесни дескриптори. Најголем дел од референците на процесите кои ги прави кернелот се преку покажувачите на процесни дескриптори. Unix типовите на оперативни системи им дозволуваат на корисниците да ги идентификуваат процесите со број наречен Process ID (PID), кој е сместен во pid полето на процесниот дескриптор. PID броевите се доделуваат секвенцијално: PID на новосоздаден процес е PID бројот на претходниот инкрементиран за еден. Како и да е, за компатибилност со традиционалните Unix системи развиени за 16-битни хардверски платформи, максималниот PID број дозволен во Linux е 32.767. Кога кернелот го создаде 32.768-миот процес во системот, тој мора да почне да ги рециклира пониските, некористени PID броеви. Од друга страна, Unix програмерите очекуваат нишките во иста група да имаат заеднички PID. На пример треба да биде можно да се испрати сигнал со специфицирање на PID кој ќе им влијае на сите нишки во групата. Всушност, POSIX 1003.1c стандардот кажува дека сите нишки од апликација со повеќе нишки мора да го имаат истиот PID. За да се усогласи со овој стандард, Linux 2.4 ја претставува нотацијата на група на нишки. Групата на нишки во основа е колекција од lightweight процеси кои одговараат на нишките од една апликација со повеќе нишки. Сите дескриптори на процесите во истата групна а нишки се собрани во двојно поврзана листа имплементирана преку полето thread_group од структурата task_struct. Идентификаторот кој се дели помеѓу нишките е PID бројот на првиот lightweight процес во групата.

Ракување со процесни дескриптори

Процесите се динамични ентитети чии животни линии траат од неколку милисекунди до неколку месеци. Поради тоа, кернелот мора да биде подготвен да се справи со многу процеси во исто време. Linux складира две различни структури на податоци во единствено мемориско поле од 8 КВ: процесниот дескпиртор и стекот за кернел мод процесите.Регистерот esp е покажувач кон стекот на ЦПЕ, кој се користи за адресирање на најгорната локација на стекот. Кај Intel системите стекот започнува од крајот и расте кон почетокот на меморискиот простор. Веднаш по префрлањето од кориснички мод во кернел мод, стекот за процес во кернелот е секогаш празен, и затоа esp регистерот покажува на бајтот кој следи веднаш по меморискиот простор за тој процес. Вредноста на esp е декрементирана веднаш откако некој податок ќе се запише во стекот. Бидејќи процесниот дескриптор е помал од 1.000 бајти, стекот на кернелот може да се прошири до 7.200 бајти. Процесниот дескриптор прикажан на слика 2.2 е сместен почнувајќи од адресата 0x015fa000, и стекот е сместен почнувајќи од адреса 0x015fc000. Вредноста на esp регистерот покажува на моменталниот врв на стекот на 0x015fa878. Кернелот ги користи alloc_task_struct и free_task_struct за да ги алоцира и ослободи 8-те КВ мемориски простор во кои се сместени процесниот дескриптор и стекот на кернелот.

Листа на процеси

За да се овозможи ефикасно пребарување низ процесите од даден тип, кернелот создава неколку листи на процеси. Секоја од нив содржи покажувачи кон процесни дескриптори. Еден покажувач од листата (полето кое секој процес го користи за да покажува на следниот процес) е вграден во податочната структура на процесниот дескриптор. Кога ќе ја погледнете декларацијата на структурата task_struct во C програмскиот јазик, дескрипторите можат да изгледаат како да покажуваат на самите себе на комплициран рекурзивен начин. Како и да е, концептот не е комплициран повеќе од една обична листа, која претставува податочна структура која содржи покажувач на следната инстанца од истата структура.Кружната двојно поврзана листа ги поврзува сите постоечки процесни дескриптори и ќе ја нарекуваме листа на процеси. За имплементација на листата се користат prev_task и next_task полињата на секој процесен дескриптор. Главата на листата е дескрипторот init_task референциран од првиот елемент на низата task, тој е предок на сите процеси и е наречен process 0 или swapper. Полето prev_task на процесот init_task покажува на процесниот дескриптор внесен последен во листата. SET_LINKS и REMOVE_LINKS се користат за внесување и бришење на процесен дескриптор од листата на процеси, соодветно. Исто така корисна функција е функцијата наречена for_each_task, која го скенира целиот процес.

Листа на TASK_RUNNING процеси

Кога бара нов процес за извршување во ЦПЕ, кернелот треба да ги земе во предвид само процесите што можат да се извршуваат (т.е. процесите во состојба TASK_RUNNING). Бидејќи е неефикасно да се скенира целата листа на процеси, се создава двојно поврзана кружна листа на TASK_RUNNING процеси наречена runqueue. Оваа листа е имплементирана преку полето run_list во процесниот дескриптор. Како во претходниот случај, процесниот дескриптор init_task ја игра улогата на хедер на листата. Варијаблата nr_running го складира вкупниот број на процеси во извршување. Функцијата add_to_runqueue( ) внесува процесен дескриптор на почетокот на листата, додека del_from_runqueue( ) брише процесен дескриптор од листата. За преместување на процес на почетокот или на крајот на листата се користат две функции: move_first_runqueue( ) и move_last_runqueue( ), соодветно. Функцијата task_on_runqueue( ) проверува дали дадениот процес е внесен во листата.

На крајот, функцијата wake_up_process( ) се користи за да го разбуди дадениот процес. Оваа функција ја поставува состојбата на процесот на TASK_RUNNING и го буди add_to_runqueue( ) за внесување на процесот во листата.

Однос со родител

Процесите кои се создадени од програма имаат однос родител-дете. Кога еден процес создава повеќе деца, овие деца имаат однос на браќа. Неколку полиња мора да бидат прикажани во процесниот дескриптор за да ги претставуваат овие врски. Процесите 0 и 1 се создадени од кернелот; процесот 1 е предок на овие односи. Дескрипторот на процес P ги опфаќа следните полиња: p_opptr (оригинален родител) Покажува на процесниот дескриптор на процесот кој го создал P или дескрипторот на процес 1(init) ако процесот родител веќе не постои. p_pptr (родител) Покажува на моменталниот родител на P (ова е процесот на кој мора да му биде сигнализирано кога процесот дете ќе заврши); неговата вредност обично се поклопува со онаа на p_opptr. Во некој случај може да биде различна, на пример кога друг процес изведува системски повик ptrace( ) со кој побарува да му дозволи да го надгледува P. p_cptr (дете) Покажува на процесниот дескриптор на најмладото дете на P – т.е. на процесот создаден најскоро. p_ysptr (помлад брат) Покажува на процесниот дескриптор на процесот кој бил креиран веднаш по P, од моменталниот родител на P. p_osptr (постар брат) Покажува на процесниот дескриптор на процесот кој бил креиран веднаш пред P, од моменталниот родител на P.

Создавање на процеси

Оперативните системи Unix претежно се потпираат на создавањето на процеси со цел да ги задоволат корисниците. Традиционалните Unix системи ги третираат сите процеси на ист начин: ресурсите кои се поседувани од процесот родител се копираат во процесот дете. Овој пристап го прави создавањето на процеси бавно и неефикасно, бидејќи е потребно да се копира целиот адресен простор на процесот родител. Процесот дете ретко има потреба да ги чита или модификува сите ресурси наследени од родителот. Модерните Unix кернели го решаваат овој проблем со претставување на три различни механизми:

• Техниката Copy On Write овозможува родителот и детето да читаат од истите физички страници. Кога еден од нив треба да запишува на физичката страна, кернелот ја копира содржината во нова физичка страна која е доделена на процесот што запишува.
• Lightweight процесите овозможуваат и родителот и детето да делат многу податочни структури од кернелот, како на пример табелите на страници, отворените датотеки со страници и сигналите.
• Системскиот повик vfork( ) создава процес кој го дели меморискиот адресен простор со неговиот родител. За да се спречи родителот да измени податоци кои му се потребни на процесот дете, извршувањето на родителот е блокирано додека детето не заврши или не започне со извршување на нова програма.