CASO

Són dues maneres de gestionar l’execució dels processos i threads de Linux (SIGSTOP/SIGCONT) i els threads de Mach (thread_suspend/thread_resume). Ens permeten aturar i permetre la seva execució.

SIGSTOP/SIGCONT es basen en signals enviats - amb la crida kill - als processos/threads, que provoquen que la seva execució s’aturi o pugui continuar. Thread_supend/thread_resume es basen en crides a sistema específiques de Mach. Diversos SIGSTOP es perden, perquè no hi ha un comptador de suspend, en canvi a Mach, thread_suspend incrementa el comptador de suspend i només quan el comptador es zero, el thread pot executar-se.

Les dues funcionalitats permeten l’execució del procés/thread indicat.

fg/bg estan relacionades amb el terminal, fg posa el procés en primer pla al terminal. bg el posa en segon pla. thread_resume només s’aplica a fluxos i no interactua amb el terminal.

Estem executant una aplicació de càlcul, o que utilitza gràfics o finestres
(podria ser un editor de text que obri la seva pròpia finestra per exemple)

I volem recuperar el control del terminal per executar altres comandes. Traiem
el gedit del primer pla del terminal:

En qualsevol moment podem fer

No serveix aquesta resposta:

Estem editant un fitxer en el terminal amb "vi prova.c" i volem executar una comanda no relacionada, per veure/fer alguna acció sobre el sistema o altres processos. Enlloc d’obrir un altre terminal, podem fer

perquè la pregunta demana un ús de bg i en aquest cas el vi en el terminal no
es pot posar en bg, perquè demana entrada/sortida i necessitarà estar en fg.

Pel fet que en l’espai d’adreces del 1r apareixen llibreries compartides i en el del segon no, la diferència és que el primer executa un fitxer binari dinàmic i el segon un estàtic.

El procés de compilació per defecte sol generar fitxers binaris dinàmics, mentre que si fem servir l’opció "-static" generarem un fitxer binari estàtic.

Són threads, cadascun dels cubs emmagatzema registres (estats del processador), ressaltant especialment la pila (SP) i el comptador de programa (PC) que apunta al codi de programa, compartit per tots els threads. El fet que dos PCs apuntin a la mateixa línia no és cap problema, car tots dos threads poden executar el mateix codi.

Per exemple, kern_return_t thread_create(task_t parent_task, thread_act_t *child_act); de macOS

Els threads són els fluxos d’execució d’una task o d’un procés.

Per exemple, kern_return_t task_create (mach_port_t parent_tas, boolean_t inherit_memory, mach_port_t* child_task); de Hurd

L’enunciat parla explícitament de la creació d’un thread al qual assignem memòria, per tant haurem de començar amb el tros de codi E (creació del thread) i haurem d’acabar amb el tros de codi A (represa del thread). En mig hem de demanar memòria i assignar-li proteccions, per tant, el tros de codi B (les proteccions) anirà just abans d’A. Queda per decidir si cridem primer a vm_map (D) o a vm_allocate ©. Teniu la pista en el control d’error de C, si l’anterior syscall ha retornat error, llavors demana memòria, això implica que el primer intent ha estat infructuós. En conseqüència, el primer intent ha estat amb vm_map.
En resum, la seqüència és E, D, C, B, A.

El fill és el procés (no pas thread) amb el pid més alt. En aquest cas el 115947 ha d’executar-se als processadors (PU) 0 i 5.

Són dos processos (que no threads), que no comparteixen memòria (l’enunciat no diu res que així ho indiqui) i tots dos estan executant un llarg loop (consum de cpu). Per tant, el cas pitjor serà si executem al mateix processador i mateix core (a). El cas millor serà el (c), diferents processadors i diferent core (no es trepitgen la cache) i el cas intermedi serà el (b) a on cadascú té un processador (PU) però han de compartir L1 i L2.
En resum c<b<a

Hi ha 5 cinc conceptes fonamentals o programming abstractions a Mach. Aquestes primitives són: Task, Thread, Port, Message i Memory Object. Expliquem nom és les tres primeres amb un exemple de syscall relacionada.

La crida al sistema clone() de Linux crea un procés que, mitjançant els arguments de la crida, pot compartir una sèrie de recursos amb el procés que ha fet la crida. En aquest sentit, fork() és una crida concreta a clone() on no és comparteix res.
En canvi, per tenir una situació semblant a Mach, hem de crear una task() (és a dir, un procés) i un thread de sistema d’aquesta tasca. Però, els threads de Mach comparteixen tots els recursos i es poden assignar a tasques diferents de la que ha fet la crida.
Els Pthreads són threads d’usuari i es gestionen mitjançant una llibreria o runtime. Són portables entre diferents sistemes operatius. En aquest sentit, la llibreria Pthread es basa en la task i el thread de Mach o en el clone de Linux, depenent on s’executi.

El nombre de bits del processador no era rellevant per a la pregunta, però vistes les vostres respostes, faig un petit aclariment. Si ens diuen que un processador és de 8 bits vol dir que el bus de dades és de 8 bits, ie, l’i8088 només podia llegir 8 bits cada vegada. Això, la Bus Interface Unit (BIU), el diferenciava de l’i8086 de 16 bits, tot i que tots dos tenien la mateixa Execution Unit (EU) i eren compatibles quant a codi assemblador. Feien servir adreçament segmentat, amb registres de segment de 16 bits i 4 bits d’offset. En conseqüència, la mida màxima de l’espai d’adreces era d'1 MB (\(2^{20}\)Bytes).

Un sistema operatiu és un programa que fa d’intermediari entre l’usuari i la màquina.
Proporciona un entorn d’execució entre convenient i eficient per executar programes.
Gestiona la màquina d’una manera segura i proporciona protecció als usuaris. Protecció és un mecanisme per a controlar l’accés de programes, processos o usuaris als recursos de l’ordinador. La seguretat protegeix la integritat de la informació emmagatzemada al sistema, així com els recursos físics d’aquest d’accessos no autoritzats. Protecció i seguretat no es poden aconseguir amb un sol mode d’execució.

Sense dos modes d’execució el sistema operatiu no pot comprovar si el procés que està executant té privilegis suficients per llançar segons quines instructions. Quan tenim dos modes d’execució i executem una syscall, el codi de kernel comprova, dins la rutina d’atenció al trap, que el procés està en mode privilegiat, si no és així genera una interrupció (a Intel, la int 13) associacda a la General Protection Fault (GPF). La resposta del sistema operatiu acostuma a ser treure al procés del sistema. Al codi es pot apreciar que les interrupcions estan inhibides (la instrucció CLI, clear interrupt-enable, posa a 0 el flag IF, veure el comentari al mateix codi). No es produeix aquest mecanisme de control.

Linux va ser creat el 1991 per Linus Torvalds quan era estudiant. S’inspirà en un microkernel didàctic anomenat MINIX, creat pel professor Andrew S. Tanenbaum el 1987. La primera versió de Linux corria sobre l’i386, aquest processador permetria anar i tornar fàcilment del mode protegit. L’i386 heretà la part de 16 bits de l’i286 (que introduí els modes d’execució a Intel) i
afegí els 32 bits. Arrancava en real-address mode, inicialitzava les estructures de dades de sistema i els registres, preparant-se per passar a protected mode. Per fi es podia implementar la protecció i seguretat, punt bàsic en la definició de sistema operatiu.

La crida al sistema mmap() assigna memòria a un procés a qualsevol punt de l’espai lògic d’aquest. Aquest fet la diferencia de sbrk() i `sbrk()', més antigues, que assignen la memória dins el heap.

Fer servir mmap() per llegir un fitxer a memòria és millor que llegir-lo amb read() si el fitxer és gran (però no massa), es farà servir moltes vegades i es compartirà (cas de les llibreries). Fer-ho així evita la funció copy_to_user() del kernel, i estalvia les crides a lseek(). Però cal tenir en compte que: hi ha un overhead significatiu en la creació del mapeig, que el fitxer hi ha de cabre dins l’espai d’adreces del procés i que el mapeig serà sempre un nombre enter de pàgines.

La funció malloc() no és una crida al sistema, sinó que pertany a la libC. Quan un procés crida a malloc() per una mida petita, malloc() crida a brk() amb una mida bastant més gran, per millorar el rendiment reduïnt el nombre de crides al sistema i administra les següents crides a malloc() sense haver d’entrar en mode privilegiat. Però si la mida demanada és molt gran, malloc() fa servir mmap() i no pas brk(), per evitar la fragmentació de memòria. Com en el cas anterior, l’overhead de mmap() només es justifica per a mides grans. Aquest llindar de separació entre cridar a brk() o a mmap() és ajustable. Veure man mallopt(3).

vm_protec() desactiva l’accés a la memòria que conté la funció dummy(), i en intentar accedir el programa termina per SIGSEGV.