Instituto Superior de Engenharia de Lisboa Licenciatura em Engenharia Informática e de Computadores

Transcrição

1 Instituto Superior de Engenharia de Lisboa Licenciatura em Engenharia Informática e de Computadores Sistemas Operativos, Verão de 2014/2015 Exame de 1ª Época Parte I Duração 1h 15m 1. [2,5] Considere um sistema de memória paginada com as seguintes características: PTE dividida em 24 bits para especificação do endereço físico e 9 bits para controlo; Dimensão de uma página igual a 8KBytes; Três níveis de tradução. Indique, apresentando os cálculos: a) [1] Qual o espaço máximo de endereçamento físico. A informação sobre as PTE permite inferir que o espaço de endereçamento físico contém 2 24 page frames (24 bits para especificação do endereço físico). Como também é dito que a dimensão da página é de 8Kbytes (2 13 bytes), o espaço de endereçamento físico máximo é assim de 2 24 x 2 13 = 2 37 bytes. b) [1] Considerando que as tabelas de páginas ocupam sempre uma página, qual o número de bits dos endereço virtual. Cada PTE ocupa 64 bits (8 bytes), pois = 33 > 32, pelo que a dimensão da PTE terá de ser a próxima potência de 2. Sabendo que todas as tabelas têm a dimensão de uma página, temos = 1024 (2 10 ) entradas por tabela de página (8Kbytes / 8 Bytes). Como também é dito que existem 3 níveis de tradução, temos 30 bits (3 x 10) para tradução de endereços. Sendo as páginas de 8 Kbytes temos 13 bits de offset, pelo que o espaço de endereçamento virtual tem 43 bits no total. c) [0,5] Se o endereço virtual for alterado para 40 bits, qual o número de bits do endereço virtual usado em cada um dos níveis de tradução. Havendo menos 3 bits usados na tradução, terão de ser retirados ao primeiro nível, que passa a usar 7 bits (2 7 = 128 entradas). O 2º e o 3º níveis continuam a usar 10 bits cada um. 2. [1,5] Na ocorrência de um Page Fault no acesso a uma página com dados iniciados não read only, identifique as transições de estado possíveis da page frame envolvida no atendimento da excepção, e as respectivas acções realizadas pelo SO até que os dados estejam disponíveis para a aplicação. No enunciado é referido que a página está iniciada com dados que podem ser modificados. Nos cenários seguintes está subjacente que o estado final da página é activo, uma vez que vai pertencer ao WS do processo. Existem duas possibilidades: o conteúdo está apenas em disco ou também está em memória (eventualmente modificado). O primeiro caso ocorre, por exemplo, no primeiro acesso. Neste caso é necessário carregar o conteúdo da página de disco para uma página física (hard page-fault) previamente obtida do estado free ou stand-by. A PTE associada à página é iniciada como acedida, não modificada e referindo a página física. O segundo caso ocorre se a página foi roubada e se encontra no estado stand-by ou modified sem ter sido ainda reutilizada por outro processo. A página é simplesmente recuperada, alterando os bits necessários na PTE (soft page-fault). Se a página roubada já foi reutilizada por outro processo, o seu conteúdo está em disco (uma nova cópia, se tiver sido modificada), pelo que um futuro acesso implica um novo hard page-fault. Nota: A resposta podia ser sintetizada apresentando o diagrama com os estados envolvidos e legendas explicativas das transições necessárias ao tratamento do page-fault. 3. [2] Como sabe, a alocação de memória virtual é feita em duas fases: a fase de reserve e a fase de commit. a) [1] Descreva, sucinta mas justificadamente, a razão de ser desse faseamento, indicando os efeitos de cada fase e apresentando pelo menos um cenário ilustrativo das suas vantagens. A fase de reserve consiste apenas na alocação de espaço de endereçamento virtual, sem nenhum mapeamento prévio. A fase de commit consistem em garantir o mapeamento (tabelas de páginas) necessário para garantir a tradução dos endereços virtuais em endereços físicos. Se o espaço commited estiver associado ao paging file para efeitos de armazenamento em disco, é também actualizado o contador que indica o total de memória commited. Em qualquer das fases não há alocação de memória física, que só ocorre quando cada página for efectivamente acedida (demand paging). Este faseamento é util sempre que se pretende garantir uma zona contígua de grande dimensão no espaço de endereçamento do processo, mas não há a certeza de vir a utilizá-la na totalidade (ex: stacks das threads).

2 b) [1] Uma das consequência da acção de commit é a eventual contribuição para a carga total na memória virtual dos sistema ( RAM + Paging File). Não sendo a memória virtual suficiente para o pedido de commit, o pedido falha de imediato, evitando a falha futura por inexistência de espaço em RAM e no Paging File. Considere o seguinte troço de código, em que handle é uma variável previamente iniciada HANDLE hm = CreateFileMapping(handle, NULL, PAGE_READWRITE, 0, 0x , NULL); LPVOID buf = MapViewOfFile(hm, FILE_MAP_WRITE, 0, 0, 0); Considerando a execução sempre bem sucedida do código anterior, indique, justificando, o aumento da carga total de commit, quando: handle refere um ficheiro regular previamente aberto com as permissões necessárias. handle vale INVALID_HANDLE_VALUE. Se o handle refere um ficheiro do sistema de ficheiros, é o próprio ficheiro que se constitui como depósito das páginas quando são transferidas para disco, não havendo incremento do contador global de memória comitted (associada ao paging file). O segundo caso, em que o handle vale INVALID_HANDLE_VALUE, é usado quando se pretende criar uma zona de memória partilhada entre processos. Neste caso é o paging file o depositário das páginas que têm de ser transferidas para disco (em situações de escassez de memória física) pelo que o total committed seria incrementado de 1 GByte, correspondendo à dimensão da região pretendida. 4. [1] Ao contrário do Windows, nos sistemas Linux a partilha de código por diferentes processos é realizada através da geração de código PIC. Apresente a solução implementada no Windows, indicando uma vantagem de uma solução em relação à outra, para cada uma delas. O código PIC, usado em geral no Unix na implementação de shared libraries, não necessita de relocalização, independentemente da região do espaço virtual em que a shared library for carregada em determinado processo. Isto é possível porque o acesso aos dados globais da DLL é sempre feito de forma indirecta (através de tabelas). No Windows as DLL s são construídas com acessos directos às suas variáveis globais. Isto torna o código mais eficiente mas obriga a relocalização, no caso da DLL não poder ser carregada, em determinado processo, na gama de endereços para o qual foi construída, o que penaliza o tempo de carregamento e o consumo de memória física (por copy on write). 5. [3] De modo a aumentar a robustez de aplicações construídas sobre a biblioteca Uthread, pretende-se acrescentar à biblioteca a possibilidade de detecção e tratamento, assim que possível, de situações de stack overflow por parte das threads em actividade. a) [1] Implemente a função BOOL UtStackOverflow(), que retorna true se a thread invocante estiver numa situação de stack overflow. Sugestão: use o endereço de uma variável local da função UtStackOverflow como estimativa do valor do stack pointer. BOOL UtStackOverflow() { char val = 0; // usado para estimar o valor do stack pointer // o valor subtraído (4096) é usado para garantir um stack mínimo de modo a tratar o erro // Este detalhe não foi tido em conta na avaliação da questão return (char *)RunningThread->Stack >= &val ; b) [1] Implemente a função VOID UtTerminate() que provoca a destruição das threads em actividade e retorna o fio de execução para a MainThread. Por simplificação, assuma que não existem threads bloqueadas. VOID UtTerminate() { // destruir todas as threads no estado ready while (!IsListEmpty(&ReadyQueue) { PLIST_ENTRY curr = RemoveHeadList(&ReadyQueue); PUTHREAD t = CONTAINING_RECORD(curr, UTHREAD, Link); CleanupThread(t); // libertar recursos // terminar a running (e única) thread retornando para MainThread InternalExit(RunningThread, MainThread);

3 c) [1] Altere as funções necessárias da biblioteca Uthread para forçar, logo que possível, o retorno da aplicação à MainThread, no caso de uma thread incorrer em stack overflow. Será apresentado na consola o nome da thread faltosa. O seguinte código devia ser colocado no início de UtYield e UtExit: if (UtStackOverflow()) { FaultingThreadId = RunningThread->Id; // assuming a thread id field in uthread UtTerminate(); Assume-se a existência do campo Id no descritor das threads (podia ser o nome), que é guardado na variável global FaultingThreadId, também acrescentada. No final de UtRun é testado valor de FaultingThreadId e apresentado o erro se o seu valor > 0. No final de UtRun fica: if (FaultingThreadId!= 0) printf("thread %d incurr in stack overflow!\n", FaultingThreadId); Nota: A razão porque não se escreve de imediato a mensagem de erro logo que se detecta a falha é a de que a thread, por definição, mesmo contando com um stack mínimo, pode não ter stack suficiente... Esta solução é apresentada como uma optimização, pois quem fez o printf de imediato não teve nenhum desconto na cotação. Parte II Duração 1h 15m 6. [2,5] Considere um serviço para envio de mensagens SMS, centrado na estrutura SMS_SERVICE. Para enviar uma mensagem, qualquer thread pode invocar a função PostSMS, que a deposita num buffer interno, notificando a sua existência através de um evento de reset automático. Esta notificação será recebida pela (única) thread responsável por ficar em ciclo a invocar TakeSMS, transmitindo cada mensagem através de um modem GSM ligado ao PC. #define NENTRIES 8 typedef char SMS[140]; typedef struct SMS_Service { HANDLE FreeEntries; // Semaphore HANDLE HasNewMessage; // AutoResetEvent LONG FirstFreeSlot; LONG FirstUsedSlot; SMS Msgs[NENTRIES]; SMS_SERVICE, *PSMS_SERVICE; SMS *GetFreeSlot(PSMS_SERVICE s) { return &s->msgs[s->firstfreeslot++ % NENTRIES]; SMS *GetUsedSlot(PSMS_SERVICE s) { return &s->msgs[s->firstusedslot++ % NENTRIES]; VOID CopySMS(SMS d, SMS s) { strcpy_s(d,sizeof(msg), s); VOID PostSMS(PSMS_SERVICE service, SMS msg) { WaitForSingleObject(service->FreeEntries, INFINITE); CopySMS(*GetFreeSlot(service), msg); SetEvent(service->HasNewMessage); VOID TakeSMS(PSMS_SERVICE service, SMS msg) { WaitForSingleObject(service->HasNewMessage, INFINITE); CopySMS(msg, *GetUsedSlot(service)); ReleaseSemaphore(service->FreeEntries, 1, NULL); O código aparenta funcionar bem desde que NENTRIES seja 1, mas noutras condições revela anomalias intermitentes, que se agravam quando há várias threads a invocar PostSMS. Explique porquê, identificando claramente os erros de sincronização presentes no código. Apresente uma versão corrigida que funcione correctamente para qualquer valor de NENTRIES e para qualquer número de threads a invocar PostSMS. Se NENTRIES for igual a 1 apenas uma thread produtora está a executar PostSMS (porque o semáforo referido por FreeEntries deve ter NENTRIES como número de unidades inicial e máximo, o que evita o acesso concorrente a PostSMS. Quando NENTRIES > 1 passa a haver acesso concorrente a PostSMS, surgindo dois tipos de problemas: o primeiro tem a ver com o acesso não protegido a FirstFreeSlot, bastando neste caso garantir o seu incremento atómico (por exemplo, usando InterlockedIncrement). O segundo problema prende-se com o facto da notificação da existência de SMS pendentes ser feita através de um evento de reset automático (referido por HasNewMessage) no qual a (única, como é dito no enunciado) thread consumidora espera incondicionalmente. Como só há uma thread consumidora, poder-se-ía usar o evento, desde que a espera sobre HasNewMessage em TakeSMS fosse condicionada ao facto de não haver SMS disponíveis. Para isso a primeira linha de TakeSMS seria substituída por: while (service->firstfreeslot == service->firstusedslot) // fila vazia! WaitForSingleObject(service->HasNewMessage, INFINITE); A outra solução (que funciona com qualquer número de threads consumidoras), seria substituir o evento por um semáforo iniciado com 0 unidades e NENTRIES como máximo. Nesse caso, apenas há que alterar a notificação em PostSMS, de SetEvent(service->HasNewMessage) para ReleaseSemaphore(service->HasNewMessage, 1, NULL). 7. [3,5] No contexto de uma infra-estrutura de suporte à paralelização de algoritmos para tirar partido de máquinas multi-

4 core, foram efectuadas as definições: typedef BOOL (*Predicate)(LPVOID elem, int index, void *ctx) DWORD ParallelCountIf( LPVOID *vals, int siz, Predicate pred, void *ctx) Implemente a função ParallelCountIf que, tirando o máximo partido dos cores existentes, invoca a função pred para os size elementos do array vals. É retornado o total de elementos que satisfazem o predicado. Assuma que o tempo de processamento de cada elemento é muito variável, pelo que uma divisão estática de trabalho não é adequada. Sugestão: as threads de processamento podem ir obtendo elas próprias os elementos que processam. typedef BOOL(*Predicate)(LPVOID elem, int index, void *ctx); typedef struct { LONG currpos; LONG size; LPVOID *vals; Predicate pred; LPVOID ctx; LONG count; PARCONTEXT; // posição corrente, partilhada por todas as worker threads // dimensão do array // array de ponteiros // predicado // contexto user // conta o número de sucessos UINT _stdcall PartialCounter(LPVOID arg) { PARCONTEXT *c = (PARCONTEXT*)arg; DWORD count = 0; while (TRUE) { int i = InterlockedIncrement(&c->currPos); if (i >= c->size) break; if (c->pred(c->vals+i, i, c->ctx)) count++; InterlockedAdd(&c->count, count); return 0; DWORD ParallelCountIf(LPVOID *vals, int size, Predicate pred, void *ctx) { // por simplicidade assumir a existência de função que indica o número de CPUs DWORD ncpus = GetNumCPUs(); HANDLE *threads = (HANDLE *) malloc(sizeof(handle)*ncpus); PARCONTEXT c; // initialize PARCONTEXT variable c.ctx = ctx; c.pred = pred; c.vals = vals; c.size = size; c.count = 0; c.currpos = -1; // de modo a que o primeiro incremento retorne 0 for (DWORD i = 0; i < ncpus; ++i) { threads[i] = (HANDLE)_beginthreadex(NULL, 0, PartialCounter, &c, 0, NULL); WaitForMultipleObjects(nCPUs, threads, TRUE, INFINITE); for (DWORD i = 0; i < ncpus; ++i) { CloseHandle(threads[i]); free(threads); return (DWORD) c.count;

5 8. [2,5] Implemente o sincronizador Barrier que permite a sincronização entre N threads participantes, de acordo com a seguinte semântica: O sincronizador é iniciado através da função Barrier_Init(CB *cb, int parties) que indica em parties o número de threads participantes. A operação Barrier_Wait bloqueia a thread invocante, enquanto a mesma operação não for invocada pela totalidade das threads participantes. A invocação da função pela última thread participante desbloqueia todas as threads. Tome em atenção que este sincronizador só pode ser usado numa única ronda de sincronização. typedef struct Barrier { HANDLE barrierreached; // evento de reset manual LONG count; BARRIER, *PBARRIER; VOID Barrier_Init(PBARRIER b, LONG count) { b->count = count; b->barrierreached = CreateEvent(NULL, TRUE, FALSE, NULL); // reset manual! // o último parceiro a invocar acorda os restantes VOID Barrier_Wait(PBARRIER b) { int res = InterlockedDecrement(&b->count); if (res == 0) { // round completes, notify SetEvent(b->barrierReached); else { // wait on specific event WaitForSingleObject(b->barrierReached, INFINITE); 9. [1,5] Comente a seguinte afirmação: Na construção de servidores de atendimento assíncrono baseados em I/O completion ports, a situação ideal para optimizar o atendimento dos pedidos, é associar à completion port, na iniciação do servidor e de forma permanente, tantas threads quantas o número de processadores da máquina onde o servidor está alojado. Depende do tipo de trabalho executado pelas threads. Se o trabalho for CPU intensive, sem bloqueios explícitos nem operações de I/O síncrono, é razoável associar à completion port tantas threads quantos os processadores disponíveis, uma vez que assim se atinge o nível de concorrência máximo possível. Se o trabalho das threads envolver bloqueios, então é possível ficar numa situação em que não existem threads disponíveis para atender conclusões de operações assíncronas, por estarem todas as threads bloqueadas. Nesse caso dever-se-ia ter mais threads associadas à completion port do que o número imposto pelo nível de concorrência. O ideal será ter um esquema dinâmico de associação de threads à completion port, criando e destruindo threads à medida das necessidades. São critérios normalmente usados para a associação de novas threads a necessidade de garantir um número mínimo de threads aptas a atender conclusões de I/O e a taxa de ocupação de CPU permancer em valores baixos (sinal de que threads que se encontram a processar conclusões se encontram bloqueadas). Um critério normalmente usado para a terminação de threads associadas é o facto destas se encontrarem há muito tempo sem realizar trabalho (à espera na fila da Completion Port). Duração Exame: 2 horas e 30 minutos ISEL, 23 de Junho de 2015