როგორ ხორციელდება მილსადენები Unix-ში

ეს სტატია აღწერს მილსადენების განხორციელებას Unix ბირთვში. მე გარკვეულწილად იმედგაცრუებული ვიყავი, რომ ბოლო სტატია სათაურით "როგორ მუშაობს მილსადენები Unix-ში?"აღმოჩნდა არარის შიდა სტრუქტურის შესახებ. დავინტერესდი და პასუხის საპოვნელად ძველ წყაროებში ჩავრთე.

რაზე ვსაუბრობთ?

Pipelines, "ალბათ ყველაზე მნიშვნელოვანი გამოგონება Unix-ში", არის Unix-ის ძირითადი ფილოსოფიის განმსაზღვრელი მახასიათებელი მცირე პროგრამების ერთმანეთთან დაკავშირების შესახებ, ისევე როგორც ნაცნობი ნიშანი ბრძანების ხაზზე:

$ echo hello | wc -c
6

ეს ფუნქცია დამოკიდებულია ბირთვის მიერ მოწოდებულ სისტემურ ზარზე pipe, რომელიც აღწერილია დოკუმენტაციის გვერდებზე მილი (7) и მილი (2):

მილსადენები უზრუნველყოფს ცალმხრივ არხს პროცესთაშორისი კომუნიკაციისთვის. მილსადენს აქვს შეყვანა (ჩაწერის დასასრული) და გამომავალი (წაკითხვის დასასრული). მილსადენის შესასვლელში ჩაწერილი მონაცემების წაკითხვა შესაძლებელია გამოსავალზე.

მილსადენი იქმნება ზარის გამოყენებით pipe(2), რომელიც აბრუნებს ფაილის ორ დესკრიპტორს: ერთი ეხება მილსადენის შეყვანას, მეორე გამომავალს.

ზემოაღნიშნული ბრძანების კვალის გამომავალი გვიჩვენებს მილსადენის შექმნას და მის მეშვეობით მონაცემთა ნაკადს ერთი პროცესიდან მეორეში:

$ strace -qf -e execve,pipe,dup2,read,write 
    sh -c 'echo hello | wc -c'

execve("/bin/sh", ["sh", "-c", "echo hello | wc -c"], …)
pipe([3, 4])                            = 0
[pid 2604795] dup2(4, 1)                = 1
[pid 2604795] write(1, "hellon", 6)    = 6
[pid 2604796] dup2(3, 0)                = 0
[pid 2604796] execve("/usr/bin/wc", ["wc", "-c"], …)
[pid 2604796] read(0, "hellon", 16384) = 6
[pid 2604796] write(1, "6n", 2)        = 2

მშობლის პროცესი ზარებს pipe()დამონტაჟებული ფაილის აღწერის მისაღებად. ერთი ბავშვის პროცესი წერს ერთ სახელურზე, ხოლო მეორე პროცესი კითხულობს იმავე მონაცემებს მეორე სახელურიდან. ჭურვი იყენებს dup2-ს 3 და 4 დესკრიპტორების "გადარქმევისთვის" stdin-ისა და stdout-ის შესატყვისად.

მილების გარეშე, ჭურვი უნდა ჩაწეროს ერთი პროცესის შედეგი ფაილში და გადასცეს სხვა პროცესს ფაილიდან მონაცემების წასაკითხად. შედეგად, ჩვენ დავხარჯავთ მეტ რესურსს და ადგილს დისკზე. თუმცა, მილსადენები კარგია არა მხოლოდ იმიტომ, რომ ისინი საშუალებას გაძლევთ თავიდან აიცილოთ დროებითი ფაილების გამოყენება:

თუ პროცესი ცდილობს წაიკითხოს ცარიელი მილსადენიდან, მაშინ read(2) დაიბლოკება მანამ, სანამ მონაცემები არ გახდება ხელმისაწვდომი. თუ პროცესი ცდილობს ჩაწეროს სრულ მილსადენზე, მაშინ write(2) დაიბლოკება მანამ, სანამ არ წაიკითხება საკმარისი მონაცემები მილსადენიდან ჩაწერის შესასრულებლად.

POSIX მოთხოვნის მსგავსად, ეს მნიშვნელოვანი თვისებაა: მილსადენზე წერა მდე PIPE_BUF ბაიტი (მინიმუმ 512) უნდა იყოს ატომური, რათა პროცესებმა შეძლონ ერთმანეთთან კომუნიკაცია მილსადენის მეშვეობით ისე, რომ რეგულარული ფაილები (რომლებიც არ იძლევა ასეთ გარანტიებს) არ შეუძლიათ.

ჩვეულებრივი ფაილის გამოყენებისას, პროცესს შეუძლია ჩაწეროს მასზე მთელი გამომავალი და გადასცეს სხვა პროცესს. ან პროცესებს შეუძლიათ იმუშაონ უაღრესად პარალელურ რეჟიმში, გარე სასიგნალო მექანიზმის გამოყენებით (როგორც სემაფორი), რათა ერთმანეთს აცნობონ ჩაწერის ან წაკითხვის დასრულებისას. კონვეიერები გვიხსნის ამ უსიამოვნებისგან.

რას ვეძებთ?

მე აგიხსნით მას მარტივი სიტყვებით, რათა გაგიადვილდეთ წარმოდგენა, როგორ მუშაობს კონვეიერი. თქვენ უნდა გამოყოთ ბუფერი და გარკვეული მდგომარეობა მეხსიერებაში. დაგჭირდებათ ფუნქციები ბუფერიდან მონაცემების დასამატებლად და ამოსაღებად. დაგჭირდებათ გარკვეული საშუალებები ფუნქციების გამოსაძახებლად ფაილის აღწერებზე წაკითხვისა და ჩაწერის ოპერაციების დროს. და დაგჭირდებათ საკეტები ზემოთ აღწერილი სპეციალური ქცევის განსახორციელებლად.

ახლა ჩვენ მზად ვართ გამოვიკითხოთ ბირთვის წყაროს კოდი ნათელი ნათურის შუქის ქვეშ, რათა დავადასტუროთ ან უარვყოთ ჩვენი ბუნდოვანი გონებრივი მოდელი. მაგრამ ყოველთვის მოემზადეთ მოულოდნელობისთვის.

სად ვეძებთ?

არ ვიცი სად არის ცნობილი წიგნის ჩემი ასლი "წიგნი ლომებიUnix 6-ის წყაროს კოდით, მაგრამ მადლობა Unix Heritage Society შეგიძლიათ მოძებნოთ ონლაინ მისამართზე საწყისი კოდი Unix-ის უფრო ძველი ვერსიებიც კი.

TUHS-ის არქივებში ხეტიალი მუზეუმის მონახულებას ჰგავს. ჩვენ შეგვიძლია გადავხედოთ ჩვენს საერთო ისტორიას და მე პატივს ვცემ მრავალწლიან ძალისხმევას, რომ ეს მასალა ეტაპობრივად აღვადგინო ძველი ფირებიდან და ანაბეჭდებიდან. და მე კარგად ვიცი იმ ფრაგმენტების შესახებ, რომლებიც ჯერ კიდევ აკლია.

კონვეიერების უძველესი ისტორიის შესახებ ჩვენი ცნობისმოყვარეობის დაკმაყოფილების შემდეგ, შედარებისთვის შეგვიძლია შევხედოთ თანამედროვე ბირთვებს.

სხვათა შორის, pipe ცხრილში არის სისტემური ზარის ნომერი 42 sysent[]. დამთხვევა?

ტრადიციული Unix ბირთვები (1970–1974)

კვალი ვერ ვიპოვე pipe(2) არც შიგნით PDP-7 Unix (1970 წლის იანვარი), არც ქ Unix-ის პირველი გამოცემა (1971 წლის ნოემბერი), არც არასრულ საწყის კოდში მეორე გამოცემა (1972 წლის ივნისი).

ამის შესახებ TUHS აცხადებს Unix-ის მესამე გამოცემა (1973 წლის თებერვალი) გახდა პირველი ვერსია კონვეიერებით:

Unix 1973rd Edition იყო ბოლო ვერსია ბირთვით დაწერილი ასამბლეის ენაზე, მაგრამ ასევე პირველი ვერსია მილსადენებით. XNUMX წელს ჩატარდა მუშაობა მესამე გამოცემის გასაუმჯობესებლად, ბირთვი გადაიწერეს C-ზე და ასე გამოჩნდა Unix-ის მეოთხე გამოცემა.

ერთმა მკითხველმა იპოვა დოკუმენტის სკანირება, რომელშიც დაგ მაკილროიმ შესთავაზა იდეა "პროგრამების დაკავშირების, როგორც ბაღის შლანგი".

ბრაიან კერნიგანის წიგნშიUnix: ისტორია და მემუარები"კონვეიერების გაჩენის ისტორიაში ეს დოკუმენტიც არის ნახსენები: "... ის კედელზე ეკიდა ჩემს ოფისში Bell Labs-ში 30 წლის განმავლობაში." Აქ ინტერვიუ მაკილროისთანდა კიდევ ერთი ამბავი მაკილროის ნამუშევარი, დაწერილი 2014 წელს:

როდესაც Unix გამოვიდა, ჩემმა გატაცებამ კორუტინებით მიბიძგა, ვთხოვე OS-ის ავტორს, კენ ტომპსონს, დაუშვას პროცესზე დაწერილი მონაცემები გადასულიყო არა მხოლოდ მოწყობილობაში, არამედ სხვა პროცესზეც. კენმა გადაწყვიტა, რომ ეს შესაძლებელი იყო. თუმცა, როგორც მინიმალისტს, მას სურდა, რომ სისტემის ყველა ფუნქციას მნიშვნელოვანი როლი ეთამაშა. არის თუ არა უშუალოდ პროცესებს შორის ჩაწერა მართლაც დიდი უპირატესობა შუალედურ ფაილზე ჩაწერასთან შედარებით? მხოლოდ მაშინ, როდესაც მე გავაკეთე კონკრეტული წინადადება მიმზიდველი სახელწოდებით „pipeline“ და პროცესებს შორის ურთიერთქმედების სინტაქსის აღწერილობით, კენმა საბოლოოდ წამოიძახა: „მე ამას გავაკეთებ!“

და გააკეთა. ერთ საბედისწერო საღამოს, კენმა შეცვალა ბირთვი და ჭურვი, დააფიქსირა რამდენიმე სტანდარტული პროგრამა, რათა სტანდარტიზებულიყო, თუ როგორ მიიღეს ისინი შეყვანის (რომელიც შეიძლება იყოს მილსადენიდან) და ასევე შეცვალა ფაილების სახელები. მეორე დღეს, მილსადენებმა დაიწყეს ძალიან ფართოდ გამოყენება აპლიკაციებში. კვირის ბოლოს მდივნები მათ იყენებდნენ ტექსტის გადამამუშავებელებიდან პრინტერში დოკუმენტების გასაგზავნად. ცოტა მოგვიანებით, კენმა შეცვალა ორიგინალური API და სინტაქსი მილსადენების გამოყენების უფრო სუფთა კონვენციებით, რომლებიც მას შემდეგ გამოიყენებოდა.

სამწუხაროდ, მესამე გამოცემის Unix ბირთვის საწყისი კოდი დაიკარგა. და მიუხედავად იმისა, რომ ჩვენ გვაქვს ბირთვის საწყისი კოდი დაწერილი C მეოთხე გამოცემაგამოვიდა 1973 წლის ნოემბერში, მაგრამ ის გამოვიდა ოფიციალურ გამოშვებამდე რამდენიმე თვით ადრე და არ შეიცავს მილსადენის დანერგვას. სირცხვილია, რომ ამ ლეგენდარული Unix ფუნქციის საწყისი კოდი დაიკარგა, შესაძლოა სამუდამოდ.

ჩვენ გვაქვს ტექსტური დოკუმენტაცია pipe(2) ორივე გამოშვებიდან, ასე რომ თქვენ შეგიძლიათ დაიწყოთ დოკუმენტაციის ძიებით მესამე გამოცემა (გარკვეული სიტყვებისთვის, ხაზგასმულია „ხელით“, ლიტერაციული სტრიქონი ^H, რასაც მოჰყვება ქვედა ხაზი!). ეს პროტო-pipe(2) დაწერილია ასამბლეის ენაზე და აბრუნებს მხოლოდ ერთი ფაილის აღწერს, მაგრამ უკვე უზრუნველყოფს მოსალოდნელ ძირითად ფუნქციონირებას:

სისტემური ზარი მილი ქმნის შეყვანის/გამოსვლის მექანიზმს, რომელსაც ეწოდება მილსადენი. დაბრუნებული ფაილის აღმწერი შეიძლება გამოყენებულ იქნას წაკითხვისა და ჩაწერის ოპერაციებისთვის. როდესაც რაღაც იწერება მილსადენში, 504 ბაიტამდე მონაცემი ბუფერდება, რის შემდეგაც ჩაწერის პროცესი ჩერდება. მილსადენიდან წაკითხვისას ბუფერული მონაცემები ამოღებულია.

მომდევნო წელს ბირთვი გადაწერილი იყო C-ში და მილი(2) მეოთხე გამოცემაში შეიძინა თავისი თანამედროვე გარეგნობა პროტოტიპთან ერთად"pipe(fildes)"

სისტემური ზარი მილი ქმნის შეყვანის/გამოსვლის მექანიზმს, რომელსაც ეწოდება მილსადენი. დაბრუნებული ფაილის აღწერები შეიძლება გამოყენებულ იქნას წაკითხვისა და ჩაწერის ოპერაციებში. როდესაც რაღაც იწერება მილსადენში, გამოიყენება r1-ში დაბრუნებული სახელური (resp. fildes[1]), ბუფერირებულია 4096 ბაიტი მონაცემებით, რის შემდეგაც ჩაწერის პროცესი შეჩერებულია. მილსადენიდან წაკითხვისას, r0-ზე დაბრუნებული სახელური (resp. fildes[0]) იღებს მონაცემებს.

ვარაუდობენ, რომ მილსადენის განსაზღვრის შემდეგ, ორი (ან მეტი) საკომუნიკაციო პროცესი (შექმნილი შემდგომი გამოძახებით ჩანგალი) გადასცემს მონაცემებს მილსადენიდან ზარების გამოყენებით წაკითხული и დაწერა.

გარსს აქვს სინტაქსი მილსადენთან დაკავშირებული პროცესების ხაზოვანი მასივის განსაზღვრისთვის.

წაკითხვის ზარები ცარიელი მილსადენიდან (რომელიც არ შეიცავს ბუფერულ მონაცემებს), რომელსაც აქვს მხოლოდ ერთი ბოლო (ჩაწერის ფაილის ყველა აღმწერი დახურულია) აბრუნებს "ფაილის დასასრულს". მსგავს სიტუაციაში წერის მოწოდებები იგნორირებულია.

ყველაზე ადრეული შემონახული მილსადენის განხორციელება შეშფოთება Unix-ის მეხუთე გამოცემამდე (1974 წლის ივნისი), მაგრამ ის თითქმის იდენტურია, რაც გამოჩნდა შემდეგ გამოშვებაში. კომენტარები ახლახან დაემატა, ასე რომ თქვენ შეგიძლიათ გამოტოვოთ მეხუთე გამოცემა.

Unix-ის მეექვსე გამოცემა (1975)

დავიწყოთ Unix კოდის კითხვა მეექვსე გამოცემა (1975 წლის მაისი). დიდწილად მადლობა ლომები მისი პოვნა ბევრად უფრო ადვილია, ვიდრე ადრინდელი ვერსიების წყაროები:

მრავალი წლის განმავლობაში წიგნი ლომები იყო ერთადერთი დოკუმენტი Unix-ის ბირთვზე, რომელიც ხელმისაწვდომი იყო Bell Labs-ის გარეთ. მიუხედავად იმისა, რომ მეექვსე გამოცემის ლიცენზიამ მასწავლებლებს საშუალება მისცა გამოეყენებინათ მისი საწყისი კოდი, მეშვიდე გამოცემის ლიცენზია გამორიცხავდა ამ შესაძლებლობას, ამიტომ წიგნი გავრცელდა უკანონო საბეჭდი ასლების სახით.

დღეს შეგიძლიათ შეიძინოთ წიგნის ხელახალი ბეჭდვა, რომლის გარეკანზე გამოსახულია სტუდენტები ასლის აპარატში. და Warren Toomey-ის წყალობით (რომელმაც დაიწყო TUHS პროექტი) შეგიძლიათ ჩამოტვირთოთ PDF ფაილი მეექვსე გამოცემის წყაროს კოდით. მინდა წარმოდგენა მოგცეთ იმის შესახებ, თუ რამდენი ძალისხმევა დაიხარჯა ფაილის შესაქმნელად:

15 წელზე მეტი ხნის წინ, მე ავკრიფე მოცემული წყაროს კოდის ასლი ლომები, რადგან არ მომეწონა ჩემი ასლის ხარისხი სხვა ასლების უცნობი რაოდენობისგან. TUHS ჯერ არ არსებობდა და მე არ მქონდა წვდომა ძველ წყაროებზე. მაგრამ 1988 წელს მე ვიპოვე ძველი 9-ტრეკიანი ლენტი, რომელიც შეიცავდა სარეზერვო ასლს PDP11 კომპიუტერიდან. ძნელი იყო იმის დადგენა, მუშაობდა თუ არა, მაგრამ იყო ხელუხლებელი /usr/src/ ხე, რომელშიც ფაილების უმეტესობას ეწერა 1979 წელი, რომელიც მაშინაც ძველად გამოიყურებოდა. ეს იყო მეშვიდე გამოცემა ან მისი წარმოებული PWB, როგორც მე მჯეროდა.

მე ავიღე აღმოჩენა, როგორც საფუძველი და ხელით ჩავასწორე წყაროები მეექვსე გამოცემაში. ზოგიერთი კოდი უცვლელი დარჩა, მაგრამ ზოგიერთის ოდნავ რედაქტირება, თანამედროვე += ჟეტონის შეცვლა მოძველებულ =+-ზე. ზოგიერთი რამ უბრალოდ წაიშალა, ზოგი კი მთლიანად გადაწერილი იყო, მაგრამ არც ისე ბევრი.

და დღეს ჩვენ შეგვიძლია წავიკითხოთ ონლაინ TUHS-ზე მეექვსე გამოცემის წყაროს კოდი არქივი, რომელზეც დენის რიჩის ხელი ეჭირა.

სხვათა შორის, ერთი შეხედვით, C-კოდის მთავარი მახასიათებელი კერნიგანისა და რიჩის პერიოდამდე არის მისი მოკლედ. ხშირად არ შემიძლია კოდის ჩასმა ვრცელი რედაქტირების გარეშე, რათა მოერგოს შედარებით ვიწრო ჩვენების არეალს ჩემს საიტზე.

ადრეული /usr/sys/ken/pipe.c არის განმარტებითი კომენტარი (და დიახ, არის უფრო მეტი /usr/sys/dmr):

/*
 * Max allowable buffering per pipe.
 * This is also the max size of the
 * file created to implement the pipe.
 * If this size is bigger than 4096,
 * pipes will be implemented in LARG
 * files, which is probably not good.
 */
#define    PIPSIZ    4096

ბუფერის ზომა არ შეცვლილა მეოთხე გამოცემის შემდეგ. მაგრამ აქ ჩვენ ვხედავთ, ყოველგვარი საჯარო დოკუმენტაციის გარეშე, რომ მილსადენები ოდესღაც იყენებდნენ ფაილებს სარეზერვო შესანახად!

რაც შეეხება LARG ფაილებს, ისინი შეესაბამება inode flag LARG, რომელსაც „დიდი მისამართების ალგორითმი“ იყენებს დასამუშავებლად არაპირდაპირი ბლოკები უფრო დიდი ფაილური სისტემების მხარდასაჭერად. ვინაიდან კენმა თქვა, რომ სჯობს არ გამოვიყენო ისინი, მე სიამოვნებით მივიღებ მის სიტყვას.

აქ არის რეალური სისტემური ზარი pipe:

/*
 * The sys-pipe entry.
 * Allocate an inode on the root device.
 * Allocate 2 file structures.
 * Put it all together with flags.
 */
pipe()
{
    register *ip, *rf, *wf;
    int r;

    ip = ialloc(rootdev);
    if(ip == NULL)
        return;
    rf = falloc();
    if(rf == NULL) {
        iput(ip);
        return;
    }
    r = u.u_ar0[R0];
    wf = falloc();
    if(wf == NULL) {
        rf->f_count = 0;
        u.u_ofile[r] = NULL;
        iput(ip);
        return;
    }
    u.u_ar0[R1] = u.u_ar0[R0]; /* wf's fd */
    u.u_ar0[R0] = r;           /* rf's fd */
    wf->f_flag = FWRITE|FPIPE;
    wf->f_inode = ip;
    rf->f_flag = FREAD|FPIPE;
    rf->f_inode = ip;
    ip->i_count = 2;
    ip->i_flag = IACC|IUPD;
    ip->i_mode = IALLOC;
}

კომენტარი ნათლად აღწერს რა ხდება აქ. მაგრამ კოდის გაგება არც ისე ადვილია, ნაწილობრივ გზის გამო.struct მომხმარებლის u» და რეგისტრირდება R0 и R1 სისტემური ზარის პარამეტრები და დაბრუნების მნიშვნელობები გადაცემულია.

მოდით ვცადოთ ialloc() დისკზე დაყენება ინოდური (ინდექსის სახელური)და დახმარებით falloc () - მოათავსეთ ორი მეხსიერებაში ფაილი. თუ ყველაფერი კარგად წავა, ჩვენ დავაყენებთ დროშებს ამ ფაილების იდენტიფიცირებისთვის, როგორც მილსადენის ორი ბოლო, მივუთითებთ მათ იმავე ინოდზე (რომლის მითითების რაოდენობა დაყენდება 2-ზე) და მოვნიშნავთ ინოდს, როგორც შეცვლილ და გამოყენებაში. ყურადღება მიაქციეთ თხოვნებს დავდე() შეცდომების ბილიკებში, რათა შემცირდეს მითითების რაოდენობა ახალ ინოდში.

pipe() უნდა გაიაროს R0 и R1 დააბრუნეთ ფაილის აღწერის ნომრები წასაკითხად და ჩასაწერად. falloc() აბრუნებს მაჩვენებელს ფაილის სტრუქტურაში, მაგრამ ასევე "აბრუნებს" მეშვეობით u.u_ar0[R0] და ფაილის აღმწერი. ანუ კოდი ინახება r ფაილის დესკრიპტორი წასაკითხად და ანიჭებს ფაილის აღწერს უშუალოდ წერისთვის u.u_ar0[R0] მეორე ზარის შემდეგ falloc().

დროშა FPIPE, რომელიც ჩვენ ვაყენებთ მილსადენის შექმნისას, აკონტროლებს ფუნქციის ქცევას rdwr() sys2.c-შიკონკრეტული I/O რუტინების დარეკვა:

/*
 * common code for read and write calls:
 * check permissions, set base, count, and offset,
 * and switch out to readi, writei, or pipe code.
 */
rdwr(mode)
{
    register *fp, m;

    m = mode;
    fp = getf(u.u_ar0[R0]);
        /* … */

    if(fp->f_flag&FPIPE) {
        if(m==FREAD)
            readp(fp); else
            writep(fp);
    }
        /* … */
}

შემდეგ ფუნქცია readp() в pipe.c კითხულობს მონაცემებს მილსადენიდან. მაგრამ უკეთესია განხორციელების თვალყურის დევნება დაწყებული writep(). ისევ და ისევ, კოდი უფრო რთული გახდა არგუმენტების გავლის კონვენციების გამო, მაგრამ ზოგიერთი დეტალი შეიძლება გამოტოვდეს.

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* If all done, return. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * If there are not both read and write sides of the
     * pipe active, return error and signal too.
     */

    if(ip->i_count < 2) {
        prele(ip);
        u.u_error = EPIPE;
        psignal(u.u_procp, SIGPIPE);
        return;
    }

    /*
     * If the pipe is full, wait for reads to deplete
     * and truncate it.
     */

    if(ip->i_size1 == PIPSIZ) {
        ip->i_mode =| IWRITE;
        prele(ip);
        sleep(ip+1, PPIPE);
        goto loop;
    }

    /* Write what is possible and loop back. */

    u.u_offset[0] = 0;
    u.u_offset[1] = ip->i_size1;
    u.u_count = min(c, PIPSIZ-u.u_offset[1]);
    c =- u.u_count;
    writei(ip);
    prele(ip);
    if(ip->i_mode&IREAD) {
        ip->i_mode =& ~IREAD;
        wakeup(ip+2);
    }
    goto loop;
}

ჩვენ გვინდა დავწეროთ ბაიტები მილსადენის შეყვანაში u.u_count. ჯერ უნდა დავკეტოთ ინოდი (იხ. ქვემოთ plock/prele).

შემდეგ ჩვენ ვამოწმებთ inode საცნობარო მრიცხველს. სანამ მილსადენის ორივე ბოლო რჩება ღია, მრიცხველი უნდა იყოს 2-ის ტოლი. ჩვენ ვატარებთ ერთ ბმულს ( rp->f_inode), ასე რომ, თუ მრიცხველი 2-ზე ნაკლებია, ეს უნდა ნიშნავდეს, რომ წაკითხვის პროცესმა დახურა მილსადენის ბოლო. სხვა სიტყვებით რომ ვთქვათ, ჩვენ ვცდილობთ ჩავწეროთ დახურულ მილსადენზე და ეს არის შეცდომა. პირველად შეცდომის კოდი EPIPE და სიგნალი SIGPIPE გამოჩნდა Unix-ის მეექვსე გამოცემაში.

მაგრამ მაშინაც კი, თუ კონვეიერი ღიაა, ის შეიძლება სავსე იყოს. ამ შემთხვევაში, ჩვენ ვათავისუფლებთ საკეტს და ვიძინებთ იმ იმედით, რომ სხვა პროცესი წაიკითხავს მილსადენიდან და გაათავისუფლებს მასში საკმარის ადგილს. გაღვიძების შემდეგ ვუბრუნდებით საწყისს, ისევ ვკიდებთ საკეტს და ვიწყებთ ჩაწერის ახალ ციკლს.

თუ მილსადენში საკმარისი თავისუფალი ადგილია, მაშინ მასში მონაცემებს ვწერთ writei ()... Პარამეტრი i_size1 inode (თუ მილსადენი ცარიელია, ის შეიძლება იყოს 0-ის ტოლი) მიუთითებს იმ მონაცემების დასასრულს, რომელსაც ის უკვე შეიცავს. თუ საკმარისი ადგილია ჩაწერისთვის, ჩვენ შეგვიძლია შევავსოთ მილსადენი i_size1 დან PIPESIZ. შემდეგ ჩვენ ვათავისუფლებთ საკეტს და ვცდილობთ გავაღვიძოთ ნებისმიერი პროცესი, რომელიც ელოდება წაკითხვას მილსადენიდან. ჩვენ ვუბრუნდებით საწყისს, რათა ვნახოთ, შევძელით თუ არა იმდენი ბაიტის დაწერა, რამდენიც გვჭირდებოდა. თუ ის ვერ მოხერხდა, მაშინ ვიწყებთ ჩაწერის ახალ ციკლს.

როგორც წესი, პარამეტრი i_mode inode გამოიყენება ნებართვების შესანახად r, w и x. მაგრამ მილსადენების შემთხვევაში, ჩვენ ვაძლევთ სიგნალს, რომ გარკვეული პროცესი ელოდება ჩაწერას ან წაკითხვას ბიტების გამოყენებით IREAD и IWRITE შესაბამისად. პროცესი აყენებს დროშას და ზარებს sleep()და მოსალოდნელია, რომ მომავალში სხვა პროცესი გამოიწვევს wakeup().

ნამდვილი მაგია ხდება sleep() и wakeup(). ისინი ხორციელდება ქ slp.c, ცნობილი "თქვენ არ გესმით ამის" კომენტარის წყარო. საბედნიეროდ, ჩვენ არ გვჭირდება კოდის გაგება, უბრალოდ გადახედეთ რამდენიმე კომენტარს:

/*
 * Give up the processor till a wakeup occurs
 * on chan, at which time the process
 * enters the scheduling queue at priority pri.
 * The most important effect of pri is that when
 * pri<0 a signal cannot disturb the sleep;
 * if pri>=0 signals will be processed.
 * Callers of this routine must be prepared for
 * premature return, and check that the reason for
 * sleeping has gone away.
 */
sleep(chan, pri) /* … */

/*
 * Wake up all processes sleeping on chan.
 */
wakeup(chan) /* … */

პროცესი, რომელიც იწვევს sleep() კონკრეტული არხისთვის შეიძლება მოგვიანებით სხვა პროცესით გამოფხიზლდეს, რაც გამოიწვევს wakeup() იგივე არხისთვის. writep() и readp() მათი მოქმედებების კოორდინაცია ასეთი დაწყვილებული ზარების მეშვეობით. გაითვალისწინე pipe.c ყოველთვის ანიჭებს უპირატესობას PPIPE როცა დარეკეს sleep(), ასე რომ ეს sleep() შეიძლება შეწყდეს სიგნალით.

ახლა ყველაფერი გვაქვს ფუნქციის გასაგებად readp():

readp(fp)
int *fp;
{
    register *rp, *ip;

    rp = fp;
    ip = rp->f_inode;

loop:
    /* Very conservative locking. */

    plock(ip);

    /*
     * If the head (read) has caught up with
     * the tail (write), reset both to 0.
     */

    if(rp->f_offset[1] == ip->i_size1) {
        if(rp->f_offset[1] != 0) {
            rp->f_offset[1] = 0;
            ip->i_size1 = 0;
            if(ip->i_mode&IWRITE) {
                ip->i_mode =& ~IWRITE;
                wakeup(ip+1);
            }
        }

        /*
         * If there are not both reader and
         * writer active, return without
         * satisfying read.
         */

        prele(ip);
        if(ip->i_count < 2)
            return;
        ip->i_mode =| IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Read and return */

    u.u_offset[0] = 0;
    u.u_offset[1] = rp->f_offset[1];
    readi(ip);
    rp->f_offset[1] = u.u_offset[1];
    prele(ip);
}

შეიძლება გაგიადვილდეთ ამ ფუნქციის წაკითხვა ქვემოდან ზევით. "წაკითხვის და დაბრუნების" ფილიალი ჩვეულებრივ გამოიყენება მაშინ, როდესაც არსებობს გარკვეული მონაცემები მილსადენში. ამ შემთხვევაში ვიყენებთ Readi () ჩვენ ვკითხულობთ იმდენ მონაცემს, რამდენიც ხელმისაწვდომია არსებულიდან f_offset წაკითხვა და შემდეგ განაახლეთ შესაბამისი ოფსეტის მნიშვნელობა.

შემდგომი წაკითხვისას, მილსადენი ცარიელი იქნება, თუ წაკითხვის ოფსეტი მიღწეულია i_size1 ინოდში. ჩვენ ვაბრუნებთ პოზიციას 0-ზე და ვცდილობთ გავაღვიძოთ ნებისმიერი პროცესი, რომელსაც სურს ჩაიწეროს მილსადენში. ჩვენ ვიცით, რომ როდესაც კონვეიერი სავსეა, writep() დაიძინებს ip+1. და ახლა, როდესაც მილსადენი ცარიელია, ჩვენ შეგვიძლია გავაღვიძოთ ის, რომ განაახლონ ჩაწერის ციკლი.

თუ წასაკითხი არაფერი გაქვთ, მაშინ readp() შეუძლია დროშის დაყენება IREAD და დაიძინე ip+2. ჩვენ ვიცით, რა გააღვიძებს მას writep(), როდესაც ის წერს ზოგიერთ მონაცემს მილსადენში.

კომენტარები readi() და writei() დაგეხმარება იმის გაგებაში, რომ პარამეტრების გადაცემის ნაცვლად "uჩვენ შეგვიძლია მათ ისე მოვექცეთ, როგორც ჩვეულებრივი I/O ფუნქციები, რომლებიც იღებენ ფაილს, ადგილს, ბუფერს მეხსიერებაში და ითვლიან წასაკითხად ან ჩასაწერი ბაიტების რაოდენობას.

/*
 * Read the file corresponding to
 * the inode pointed at by the argument.
 * The actual read arguments are found
 * in the variables:
 *    u_base        core address for destination
 *    u_offset    byte offset in file
 *    u_count        number of bytes to read
 *    u_segflg    read to kernel/user
 */
readi(aip)
struct inode *aip;
/* … */

/*
 * Write the file corresponding to
 * the inode pointed at by the argument.
 * The actual write arguments are found
 * in the variables:
 *    u_base        core address for source
 *    u_offset    byte offset in file
 *    u_count        number of bytes to write
 *    u_segflg    write to kernel/user
 */
writei(aip)
struct inode *aip;
/* … */

რაც შეეხება "კონსერვატიულ" ბლოკირებას, მაშინ readp() и writep() დაბლოკეთ ინოდი, სანამ არ დაასრულებენ სამუშაოს ან არ მიიღებენ შედეგს (ანუ დარეკეთ wakeup). plock() и prele() იმუშავეთ მარტივად: ზარების სხვადასხვა ნაკრების გამოყენებით sleep и wakeup საშუალებას გვაძლევს გავაღვიძოთ ნებისმიერი პროცესი, რომელსაც სჭირდება საკეტი, რომელიც ახლახან გავათავისუფლეთ:

/*
 * Lock a pipe.
 * If its already locked, set the WANT bit and sleep.
 */
plock(ip)
int *ip;
{
    register *rp;

    rp = ip;
    while(rp->i_flag&ILOCK) {
        rp->i_flag =| IWANT;
        sleep(rp, PPIPE);
    }
    rp->i_flag =| ILOCK;
}

/*
 * Unlock a pipe.
 * If WANT bit is on, wakeup.
 * This routine is also used to unlock inodes in general.
 */
prele(ip)
int *ip;
{
    register *rp;

    rp = ip;
    rp->i_flag =& ~ILOCK;
    if(rp->i_flag&IWANT) {
        rp->i_flag =& ~IWANT;
        wakeup(rp);
    }
}

თავიდან ვერ მივხვდი რატომ readp() არ იწვევს prele(ip) ზარის წინ wakeup(ip+1). პირველი რაც არის writep() იწვევს თავის ციკლში, ეს plock(ip), რასაც ჩიხში მივყავართ თუ readp() ჯერ არ მომიშორებია ჩემი ბლოკი, ასე რომ რატომღაც კოდი სწორად უნდა მუშაობდეს. თუ შეხედავთ wakeup(), მაშინ ცხადი ხდება, რომ ის მხოლოდ ძილის პროცესს აღნიშნავს, როგორც მზადაა შესასრულებლად, ისე რომ მომავალში sched() მართლაც დაიწყო. Ისე readp() მიზეზები wakeup(), ხსნის საკეტს, აყენებს IREAD და რეკავს sleep(ip+2)- ეს ყველაფერი ადრე writep() განაახლებს ციკლს.

ეს ავსებს კონვეიერების აღწერას მეექვსე გამოცემაში. მარტივი კოდი, შორსმიმავალი შედეგები.

Unix-ის მეშვიდე გამოცემა (1979 წლის იანვარი) იყო ახალი ძირითადი გამოშვება (ოთხი წლის შემდეგ), რომელმაც შემოიტანა მრავალი ახალი აპლიკაცია და ბირთვის ფუნქცია. მან ასევე განიცადა მნიშვნელოვანი ცვლილებები სტრუქტურების ტიპის ჩამოსხმის, გაერთიანებებისა და აკრეფილი მაჩვენებლების გამოყენებასთან დაკავშირებით. თუმცა კონვეიერის კოდი პრაქტიკულად უცვლელი. ჩვენ შეგვიძლია გამოვტოვოთ ეს გამოცემა.

Xv6, მარტივი Unix-ის მსგავსი ბირთვი

ბირთვის შესაქმნელად Xv6 Unix-ის მეექვსე გამოცემის გავლენის ქვეშ, მაგრამ ის დაწერილია თანამედროვე C-ზე, რომ იმუშაოს x86 პროცესორებზე. კოდი ადვილად წასაკითხი და გასაგებია. გარდა ამისა, Unix-ის წყაროებისგან განსხვავებით TUHS-ით, შეგიძლიათ შეადგინოთ იგი, შეცვალოთ და გაუშვათ სხვა რამეზე, გარდა PDP 11/70. ამიტომ, ეს ბირთვი ფართოდ გამოიყენება უნივერსიტეტებში, როგორც საგანმანათლებლო მასალა ოპერაციული სისტემების შესახებ. წყაროები არიან Github-ზე.

კოდი შეიცავს მკაფიო და გააზრებულ განხორციელებას მილი.გ, მხარდაჭერილი ბუფერით მეხსიერებაში დისკზე ინოდის ნაცვლად. აქ მე გთავაზობთ მხოლოდ „სტრუქტურული მილსადენის“ განმარტებას და ფუნქციას pipealloc():

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() ადგენს დანარჩენი განხორციელების მდგომარეობას, რომელიც მოიცავს ფუნქციებს piperead(), pipewrite() и pipeclose(). სისტემური ზარი sys_pipe არის შეფუთვა დანერგილი sysfile.c. გირჩევთ წაიკითხოთ მისი მთელი კოდი. სირთულე მეექვსე გამოცემის წყაროს კოდის დონეზეა, მაგრამ მისი წაკითხვა ბევრად უფრო ადვილი და სასიამოვნოა.

Linux 0.01

Linux 0.01 წყაროს კოდი შეგიძლიათ იხილოთ. სასწავლო იქნება მილსადენების განხორციელების შესწავლა მის fs/pipe.c. ეს იყენებს ინოდს მილსადენის წარმოსადგენად, მაგრამ თავად მილსადენი დაწერილია თანამედროვე C-ში. თუ თქვენ გაიარეთ მე-6 გამოცემის კოდი, აქ პრობლემა არ გექნებათ. ასე გამოიყურება ფუნქცია write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

სტრუქტურის განმარტებების გარეშეც კი, შეგიძლიათ გაარკვიოთ, თუ როგორ გამოიყენება ინოდის მითითების რაოდენობა, რათა შეამოწმოთ, შედეგია თუ არა ჩაწერის ოპერაცია SIGPIPE. ბაიტი-ბაიტი მუშაობის გარდა, ეს ფუნქცია მარტივია შედარება ზემოთ აღწერილ იდეებთან. თუნდაც ლოგიკა sleep_on/wake_up არც ისე უცხოდ გამოიყურება.

თანამედროვე Linux ბირთვები, FreeBSD, NetBSD, OpenBSD

სწრაფად გავიარე რამდენიმე თანამედროვე ბირთვი. არცერთ მათგანს აღარ აქვს დისკის დანერგვა (გასაკვირი არ არის). Linux-ს აქვს საკუთარი იმპლემენტაცია. მიუხედავად იმისა, რომ სამი თანამედროვე BSD ბირთვი შეიცავს ჯონ დაისონის მიერ დაწერილ კოდზე დაფუძნებულ იმპლემენტაციას, წლების განმავლობაში ისინი ძალიან განსხვავდებიან ერთმანეთისგან.

Წაკითხვა fs/pipe.c (Linux-ზე) ან sys/kern/sys_pipe.c (*BSD-ზე), ამას ნამდვილი თავდადება სჭირდება. დღევანდელი კოდი ეხება შესრულებას და ისეთი ფუნქციების მხარდაჭერას, როგორიცაა ვექტორული და ასინქრონული I/O. და მეხსიერების განაწილების, ბლოკირების და ბირთვის კონფიგურაციის დეტალები ძალიან განსხვავდება. ეს არ არის ის, რაც კოლეჯებს სჭირდებათ ოპერაციული სისტემების შესავალი კურსისთვის.

ყოველ შემთხვევაში, მე მაინტერესებდა ძველი შაბლონების გათხრა (როგორიცაა გენერირება SIGPIPE და დაბრუნდი EPIPE დახურულ მილსადენზე ჩაწერისას) ყველა ამ სხვადასხვა თანამედროვე ბირთვში. მე ალბათ ვერასდროს ვიხილავ PDP-11 კომპიუტერს რეალურ ცხოვრებაში, მაგრამ ჯერ კიდევ ბევრი რამ არის სასწავლი კოდიდან, რომელიც დაიწერა ჩემს დაბადებამდე წლებით ადრე.

დივი კაპურის მიერ 2011 წელს დაწერილი სტატია:მილებისა და FIFO-ების Linux ბირთვის დანერგვა" გთავაზობთ მიმოხილვას, თუ როგორ მუშაობს მილსადენები (ჯერ კიდევ) Linux-ში. ა უახლესი ჩადენა Linux-ში ასახავს მილსადენის ურთიერთქმედების მოდელს, რომლის შესაძლებლობები აღემატება დროებით ფაილებს; და ასევე აჩვენებს, თუ რამდენად შორს წავიდა მილსადენები Unix-ის მეექვსე გამოცემის ბირთვის "ძალიან კონსერვატიული ჩაკეტვისგან".

წყარო: www.habr.com