Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-07-12T12:30:10Z
No. of bitstreams: 2
license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5)
DISSERTAÇÃO (2015-08-17) - RAFAEL BRANDAO LOBO.pdf: 1015468 bytes, checksum: d543b6f16adc4ce4d3aa4d59c8d546ff (MD5) / Made available in DSpace on 2016-07-12T12:30:10Z (GMT). No. of bitstreams: 2
license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5)
DISSERTAÇÃO (2015-08-17) - RAFAEL BRANDAO LOBO.pdf: 1015468 bytes, checksum: d543b6f16adc4ce4d3aa4d59c8d546ff (MD5)
Previous issue date: 2015-07-17 / CAPEs / Deadlocks are a common type of concurrency bug. When a deadlock occurs, it is difficult
to clearly determine whether there is an actual deadlock or if the application is slow or hanging
due to a different reason. It is also difficult to establish the cause of the deadlock. In general,
developers deal with deadlocks by using analysis tools, introducing application-specific deadlock
detection mechanisms, or simply by using techniques to avoid the occurrence of deadlocks by
construction. In this paper we propose a different approach. We believe that if deadlocks manifest
at runtime, as exceptions, programmers will be able to identify these deadlocks in an accurate
and timely manner. We leverage two insights to make this practical: (i) most deadlocks occurring
in real systems involve only two threads acquiring two locks (TTTL deadlocks); and (ii) it’s
possible to detect TTTL deadlocks efficiently enough for most practical systems. We conducted
a study on bug reports and found that more than 90% of identified deadlocks were indeed
TTTL.We extended Java’s ReentrantLock class to detect TTTL deadlocks and measured the
performance overhead of this approach with a conservative benchmark. For applications whose
execution time is not dominated by locking, the overhead is estimated as below 6%. Empirical
usability evaluation in two experiments showed that students finished tasks 16.87% to 30.7%
faster on the average using our approach with the lock being the most significant factor behind
it, and, in one of the experiments they were able to identify the defects more accurately with a
signficant 81.25% increase in the number of correct answers when deadlock exceptions where
present. / Deadlocks são um tipo comum de bug de concorrência. Quando um deadlock acontece, é difícil determinar claramente se houve um deadlock de verdade ou se a aplicação está lenta ou travada por qualquer outro motivo. Também é difícil estabelecer a causa do deadlock. Em geral, desenvolvedores lidam com deadlocks de várias maneiras: utilizando ferramentas analíticas; utilizando mecanismos especificos da aplicação para detectar deadlocks; ou simplesmente usando técnicas para evitar a ocorrência de deadlocks no momento da construção do código. Neste trabalho, propomos uma abordagem diferente. Acreditamos que se deadlocks se manifestarem durante a execução na forma de exceções, programadores serão capazes de identificar esses deadlocks de forma mais precisa e mais rápida. Levamos em consideração alguns aspectos para tornar esta abordagem prática: (i) a maioria dos deadlocks que ocorrem em sistemas reais envolvem apenas duas threads adquirindo dois locks ou two-thread, two-lock (TTTL) deadlock; e (ii) é possível detectar TTTL deadlocks de forma suficientemente eficiente para uso prático na maioria dos sistemas. Conduzimos um estudo com bugs reportados em sistemas de software de larga escala e descobrimos que mais de 90% dos bugs identificados como deadlocks eram de fato TTTL. Extendemos a classe ReentrantLock de Java para detectar TTTL deadlocks e medimos seu overhead na performance com um benchmark bastante conservador onde medimos o overhead das operações de trava quando deadlocks não são possíveis. Para aplicações cujo tempo de execução não é dominado por travas, o impacto médio no tempo de execução é na ordem de 6%. Realizamos uma avaliação empírica para testar usabilidade através de dois experimentos. Nesta avaliação, mostramos que, em média, estudantes terminam tarefas de 16.87% a 30.7% mais rapidamente usando nossa abordagem, sendo o tipo de abordagem o fator de maior significância e, em um dos experimentos, estudantes foram capazes de identificar mais corretamente a causa dos bugs, mostrando que o número de respostas corretas aumentou significativamente em 81.25% quando as exceções propostas estavam presentes.
| Identifer | oai:union.ndltd.org:IBICT/oai:repositorio.ufpe.br:123456789/17332 |
| Date | 17 August 2015 |
| Creators | LÔBO, Rafael Brandão |
| Contributors | http://lattes.cnpq.br/7310046838140771, LIMA FILHO, Fernando José Castor de |
| Publisher | Universidades Federais de Pernambuco, Programa de Pos Graduacao em Ciencia da Computacao, UFPE, Brasil |
| Source Sets | IBICT Brazilian ETDs |
| Language | English |
| Detected Language | Portuguese |
| Type | info:eu-repo/semantics/publishedVersion, info:eu-repo/semantics/masterThesis |
| Source | reponame:Repositório Institucional da UFPE, instname:Universidade Federal de Pernambuco, instacron:UFPE |
| Rights | Attribution-NonCommercial-NoDerivs 3.0 Brazil, http://creativecommons.org/licenses/by-nc-nd/3.0/br/, info:eu-repo/semantics/openAccess |
Page generated in 0.0161 seconds