Parallel Refal - програмен език Refal Plus
Навигация
Скорошна активност на сайта
Паралелно реф
Първият подход. Изричен паралелизъм.
Този подход е подобен на MPI, но в MPI процесите се раждат при стартиране и нишките могат лесно да бъдат породени по време на изпълнение. В доклада на това място може да се предположи кое е по-добро и кое е по-подходящо за функционалните езици като цяло и по-специално за Refal +;).
Функция за хвърляне на нишка - подобно на Прилагане, но не връща нищо.
Изпращане-получаване
И са необходими изрични конструкции за синхронизиране/предаване на съобщения. Може да се направи както в MPI или като в Erlang - идентификация по номера, но ми се струва, че специална пощенска кутия MsgBox би била по-подходяща за Refal +. Донякъде е подобна на Refal + 'ovsky box, в която някои хора поставят, други - извадете ... (Това може да се обсъди и в доклада;))
В резултат се нуждаем от функциите за отваряне на кутия, изпращане и получаване:
Има две функции за приемане - блокиране и неблокиране. Ако в пощенската кутия няма съобщения, първото отива в режим на заспиване и чака, а второто връща $ неуспех.
Семантиката на Send/Recv е абсолютно същата като в MPI: всяко изпращане на повикване съответства на точно едно успешно приемане.
Монотонни обекти
Такива кутии могат да се използват за едно предаване на данни между нишки.
Един от най-често използваните начини за използване на SOBox е предаването на резултата от дадена функция през тях. За това дефинираме функцията
Втори подход. Неявна паралелност.
Този подход е вдъхновен от Т-системата и други неявни паралелности във функционалните езици. А също и изрична схема с монотонни обекти
Идея 1 - всяко извикване на функция може да се изпълнява паралелно (или да не се брои на мързеливи езици), стига резултатите от функцията да не са наистина необходими.
Идея 2 - направете монотонните обекти неявни (срещу схема с монотонни обекти).
Този подход е много по-лесен за споделената памет, отколкото в OpenTS, тъй като не е нужно да мислите за разпространение на данни. И за начало използвайте Java нишки (подобно на това как TSim използва системни нишки, а OpenTS, напротив, използва свои собствени нишки). Възможно е нишките на Java да са достатъчни. Имам мечта да поставя Solaris някъде да експериментира - има някои интересни неща, които не са в света на Linux. Един от тях са леки нишки.