Всем доброго вечера.
Когда Иван читал у нас, на мех-мате в Каразина свой спецкурс у меня появилась навящевая идея по поиску дедлоков без запуска программы, только на основании ее кода. Было сделано несколько попыток найти какой-то внятный алгоритм. К настоящему моменту я достаточно неплохо, как мне кажется, продвинулся в этом направлении.
Чтобы не усложнять до предела работу по парсингу кода на Java или C я написал простой язык для описания потоков.
суббота, 26 марта 2011 г.
среда, 16 марта 2011 г.
среда, 9 марта 2011 г.
вторник, 8 марта 2011 г.
habrahabr: Обзор NoSQL систем
Обзор NoSQL систем
Cassandra, HBase, Riak, Scalaris, Voldemort, CouchDB, MongoDB, Neo4j, Redis, Tokyo Cabinet
Cassandra, HBase, Riak, Scalaris, Voldemort, CouchDB, MongoDB, Neo4j, Redis, Tokyo Cabinet
понедельник, 7 марта 2011 г.
A Note on Distributed Computing
A Note on Distributed Computing
Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application level programmers and designers if one is to take distribution seriously.
Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application level programmers and designers if one is to take distribution seriously.
Oracle Coherence: author blog
Обнаружен блог Cameron Purdy.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
среда, 2 марта 2011 г.
Deep-deep-deep Google internals: Chubby
1. "The Chubby Lock Service for Loosely-Coupled Distributed Systems"
Mike Burrows, Google Inc.
Abstract
We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance. Many instances of the service have been used for over a year, with several of them each handling a few tens of thousands of clients concurrently. The paper describes the initial design and expected use, compares it with actual use, and explains how the design had to be modified to accommodate the differences.
OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.
"We expected Chubby to help developers deal with coarse-grained synchronization within their systems, and in particular to deal with the problem of electing a leader from among a set of otherwise equivalent servers. For example, the Google File System [7] uses a Chubby lock to appoint a GFS master server, and Bigtable [3] uses Chubby in several ways: to elect a master, to allow the master to discover the servers it controls, and to permit clients to find the master. In addition, both GFS and Bigtable use Chubby as a well-known and available location to store a small amount of meta-data; in effect they use Chubby as the root of their distributed data structures. Some services use locks to partition work (at a coarse grain) between several servers."
-------------
"Paxos Made Live - An Engineering Perspective"
Paxos Made Live - An Engineering Perspective
Tushar Chandra
Robert Griesemer
Joshua Redstone
June 20, 2007
Abstract
We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.
Mike Burrows, Google Inc.
Abstract
We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance. Many instances of the service have been used for over a year, with several of them each handling a few tens of thousands of clients concurrently. The paper describes the initial design and expected use, compares it with actual use, and explains how the design had to be modified to accommodate the differences.
OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.
"We expected Chubby to help developers deal with coarse-grained synchronization within their systems, and in particular to deal with the problem of electing a leader from among a set of otherwise equivalent servers. For example, the Google File System [7] uses a Chubby lock to appoint a GFS master server, and Bigtable [3] uses Chubby in several ways: to elect a master, to allow the master to discover the servers it controls, and to permit clients to find the master. In addition, both GFS and Bigtable use Chubby as a well-known and available location to store a small amount of meta-data; in effect they use Chubby as the root of their distributed data structures. Some services use locks to partition work (at a coarse grain) between several servers."
-------------
"Paxos Made Live - An Engineering Perspective"
Paxos Made Live - An Engineering Perspective
Tushar Chandra
Robert Griesemer
Joshua Redstone
June 20, 2007
Abstract
We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.
вторник, 1 марта 2011 г.
Ищу работу
Добрый день.
Я подумываю о смене работы.
Ищу пописать какую-нибудь низкоуровневую распределенную инфраструктуру на основе Netty/JGroups/etc.
Или сервер многопоточный какой.
Или распределенной хранилище данных.
Или инфраструктуру для MMOGame.
Или поюзать какую-нибудь низкоуровневую распределенную инфраструктуру: Cassandra, HBase, HDFS, Hadoop, PIG, etc
Бизнес-проекты на {GWT,JSF}/{Spring, EJB}/Hibernate/RDBMS пока не рассматриваю.
Рассмотрю любой город бСССР и любой режим работы.
Могу менторить юниоров.
К "печенькам" не требователен.
P.S. Golovach.Ivan@gmail.com
P.P.S. На письма вида "высылайте резюме, а потом мы вам как-нибудь расскажем про проект" не отвечу.
Я подумываю о смене работы.
Ищу пописать какую-нибудь низкоуровневую распределенную инфраструктуру на основе Netty/JGroups/etc.
Или сервер многопоточный какой.
Или распределенной хранилище данных.
Или инфраструктуру для MMOGame.
Или поюзать какую-нибудь низкоуровневую распределенную инфраструктуру: Cassandra, HBase, HDFS, Hadoop, PIG, etc
Бизнес-проекты на {GWT,JSF}/{Spring, EJB}/Hibernate/RDBMS пока не рассматриваю.
Рассмотрю любой город бСССР и любой режим работы.
Могу менторить юниоров.
К "печенькам" не требователен.
P.S. Golovach.Ivan@gmail.com
P.P.S. На письма вида "высылайте резюме, а потом мы вам как-нибудь расскажем про проект" не отвечу.
Подписаться на:
Сообщения (Atom)