-
Se as threads vao executarem de maneira concorrente, vai fazer com que o processo termine em menos termpo! Não entendi a resposta!
-
Rogério, a decomposição de um processo em várias threads não significa, necessariamente, que este será executado em menos tempo. Nesses casos deve ser considerada a possibilidade de execução paralela.
-
Um sistema peer ro peer (par-a-par), como o nome indica, se refere a uma interação entre 2 (dois) pares, não caracterizando, portanto, um sistema onde interagem vários computadores.
Por outro lado, o uso de multi-threading tem o objetivo de paralelizar as operações e obter melhor performance, embora isto somente seja alcançavel se o hardware tiver recursos para esta paralelização.
-
a) O fato de transferir complexidade do software para o hardware confere à arquitetura CISC a capacidade de facilitar o trabalho do programador. Sim, a arquitetura CISC possui centenas de instruçoes já prontas, tendo o programador apenas a tarefa de conheçe-las para programar a arquitetura do processador. b) Peer-to-peer pode ser entendida como uma arquitetura tipicamente distribuída, tendo em vista seu objetivo de explorar recursos, tanto de hardware quanto de software, de um grande número de computadores para cumprimento de uma tarefa ou atividade. Sim, na arquitetura P2P, há vários dispositivos de hardwares(computadores), q interagem via software(Kazaa, emule etc) para realizar uma tarefa, por exemplo, baixar um filme. c) O suporte a threads num sistema operacional tem como propósito permitir que um processo decomposto em vários threads seja executado em menos tempo. Errado! Nunca confunda threads com processos. São coisas distintas. A paralelização tanto de um como de outro não é possivel, porem, no caso das threads, a alternancia entre elas num mesmo processo é bem mais rápida, pela ausencia de troca de contexto. Sistemas multithreading não são usados para q o processo seja executado mais rapidamente, mas para q mais tarefas(processos) sejam executadas ao mesmo tempo. Ou seja, ela permite apenas q muitas atividades sejam executadas ao mesmo tempo, mas isso não significa q um processo termine mais rapido. Como exemplo ilustrativo, imagine q um usuario q usa sistemas mutlthread precise executar tres procesos, como o word, o media player e o IE8. Ele conseguirá executa-los os 3 ao mesmo tempo com bom desempenho; porem, o processo word, individualmente, levara o mesmo tempo para ser executado no caso se fosse monothread. Sendo monothread, os tres apliccativos citados levariam mais tempo. Ou seja, a vatangem multithread está no conjunto dos processos a executar. Individualmente, a execução continua a mesma. d) O desempenho de um sistema de arquivos pode ser melhorado de várias maneiras, dentre as quais, a leitura antecipada e a colocação cuidadosa dos blocos de um arquivo próximos uns dos outros. Sim, a leitura antecipada deixa o arquivo disponivel antes mesmo de ele ser requisitado, o q evita ter q buscar o arquivo depois; já deixar os blocos de arquivos proximos, faz com q a varredura do cabeçote de leitura do HD leia varios blocos em sequencia, ao inves de ter q procurar blocos em diferentes posicoes(para isso se usa o desfragmentador de discos). e) Determinar como um recurso é compartilhado é tarefa do sistema operacional, por meio do gerenciamento do tempo e do espaço. Como tô respondendo as questoes de cabeça, vou pesquisar ainda sobre essa.
-
Vou citar um exemplo de uso de thread que foi necessário na empresa onde trabalhava e que não tem nada a ver com ganho de performance e velocidade:
Era um sistema web, que tinha um relatório pesadíssio pra rodar. Acontece que esse relatório, além de trazer as informações, ele alterava registros no banco (pra marcar que aquela informação já foi mostrada no relatório, e não teria que ser exibida em um novo relatório). Como era grande e lento, as vezes o usuário cancelava o processo no meio, e aí já viu. Estragava tudo.
A solução foi criar uma thread para o relatório. O cara clicava pra gerar, e aí a thread era iniciada. Quando o relatório estivesse pronto, ele ia ver na tela. Não precisava mais ficar esperando terminar.
Não sei se fui claro, mas nesse caso, não tem a ver com tempo. O tempo de geração do relatório é basicamente o mesmo.
-
Uma parábola para a trhead:
Temos dois carros, x e y, que andam a 100km/h. Ambos precisam chegar numa cidade que está a 100 km de distância e dentro de 1 hora.
Sem thread: o carro x irá sozinho até a cidade. Após chegar o carro y poderá iniciar a viagem. Resumo: tempo gasto por x = 1h; tempo gasto por y = 1h; x + y = 2h.
Com thread: o carro x irá sozinho até a metade do caminho e parará, então o carro y poderá iniciar viagem indo também até a metade do caminho e parando. O carro x retomará viagem até concluir. Após x chegar no final, y retomará até concluir.
Resumo:
x = 0,5h (andou 50 km e parou);
y = 0,5h (andou 50 km e parou);
x = x + 0,5h (andou + 50 km);
y = y + 0,5h (andou + 50 km);
x + y = 2h
Conclusão: mesmo tempo total para conclusão!
Fonte: massa cefálica de 1.500 ml :P
-
A alternativa "a" também não estaria incorreta? Veja, ela afirma que CISC transfere a complexidade do software para o hardware... Não seria o contrário?
-
Airton Junior,
Marquei a A justamente por isso. Também acredito que esteja incorreta.
-
CISC facilita a vida do programador (de baixo nível) pois fornece muitas instruções em variados formatos de forma que é provável que sempre exista uma que irá facilitar a vida do programador. Já o RISC por ter menos instruções, tem de confiar muito na tecnologia de compiladores para ser capaz de traduzir uma instrução (em linguagem de alto nível) para a um conjunto de intruções (software) de baixo nível capaz de executá-la.
Só acredito que o item A se equivoca ao não restringir e dizer facilitar o trabalho do programador de baixo nível. Afinal isso só faz sentido quando falamos em linguagem de montagem. Pra quem programa Java, ou mesmo C por exemplo, não faz diferença se o processador é x86 ou ARM.
-
Alguém explica a E?
-
Explicando a letra E:
Gerenciamento do tempo está normalmente associado ao uso do processador. Por exemplo, pode-se citar o "time-slice", em que cada processo terá uma fatia de tempo para o uso do processador. O "tempo real" tbém é uma forma de Gerenciamento do tempo, onde um processo de maior prioridade tomará o uso do processador.
Gerenciamento do espaço está normalmente associado ao uso da memória. Ex.: Quando um processo é criado, o sistema operacional cria um espaço de endereçamento alocado exclusivamente ao processo. Quando uma thread é criada, o SO compartilha o espaço de endereçamento do processo ao qual ele está vinculado e esse compartilhamento está associado ao gerenciamento no mesmo espaço de memória.
-
FCC é bisonha nas questões de TI, tem a mania de a assertiva sempre ser a mais certa ou a mais errada pra se gabaritar
sobre threads, não é garantido que seu processo execute em menos tempo
Multiprocessadores: Sim
monoprocessador: nao
-
a A está completamente correta, você pode usar até para estudar, CISC é isso aí, e ele tem instruções complexas e é mais lento que os RISC que têm instruções simples, mas é bem mais difícil programar para RISC, quem já usou Assembly sabe bem.
-
Na internet encontrei a seguinte resposta para letra C:
O suporte a threads num sistema operacional justifica-se porque:
Correct Answer:
Simplifica a programação de aplicações com muitas atividades simultâneas.