Хорошая книжка по многопоточности?

Интересны атомарные операции, optimistic locks, неблочащиеся структуры данных, транзакционность в многопоточном окружении, применение этого всего на практике(без привязки к какому-то API).
Мьютексы/семафоры/баяны не интересны.

Буржуйским владею.

 

первая на вскидку
http://www.ebook-4download.com/2010/10/multithreading-applications-in-win32/

если кому надо - cd к книге нашлось 8мег
http://www.informit.com/title/0201442345
http://www.informit.com/content/images/0201442345/CDContents/CDcontents.zip

 

http://www.books.ru/shop/books/357604

 

Увы, обе книги слишком стары - они про пессимистичные блокировки и соответствующее API.

 

scf
Ты хоть одну из них читал?
прежде чем ***** всякую говорить...
?

 

featurelles
Просмотрел. В твоей про атомарные операции ровно 2 страницы текста + описание API + пара примеров... В соответствующем разделе, "атомарные операции".
К сожалению, этого мне недостаточно.

 

scf
У меня вопрос.
"неблочащиеся структуры данных, транзакционность в многопоточном окружении"
Здесь нет противоречия?

 

Вообще нет.
Используя версионность данных, создание копий и "правильный" порядок обновления элементов данных, можно добиться транзакционности. Как при этом резолвить конфликты - это, конечно, уже отдельный вопрос
Применения:
-sql server snapshot isolation
-облачные/кластерные базы - master-to-master replication
-практическое применение документ-ориентированных СУБД.
Они предоставляют по сути то же API, что и атомарные операции - get-and-set и т.п.
Мне не особо хочется изобретать велосипеды, вот и интересуюсь, может их кто-то изобрел до меня...

edit: еще забавная штука - структуры данных на атомарных операциях - очереди, стеки, может даже ассоциативные массивы... Они используют оптимистичную блокировку и поэтому куда шустрее классических реализаций на мьютексах. Вот только инфу о принципах построения таких вещей фиг найдешь.

 

scf
Спасибо за ответ.
Если тут чтонить дельное посоветуют, тоже почитаю.

 

scf
Хороших книг не видел.

А вы уверены что оптимистическая блокировка связана с атомарными операциями?

Там не сложно. Только я пришёл к выводу что при параллельном программировании используются другие структуры и механизмы и их больше чем классических. Классические хотя и лежат в основе, но как по мне это уже новые структуры.

 

Гуг сразу выдал про неблокирующие структуры стек,очередь и тд.
http://www.ibm.com/developerworks/ru/library/j-jtp04186/index.html

 

Pavia
Ну как
Я всегда считал, что оптимистичная(или оптимистическая? optimistic lock короче) блокировка - это когда сначала разделяемый ресурс захватывается, а уже потом определяется, был ли конфликт при захвате. Если конфликт был - то операция повторяется позже. И я в курсе всего о двух механизмах синхронизации - блокирующий(мьютексы и производные от них) и атомарные операции. Т.е. т.к. на мьютексах такое не сделаешь, то остаются только атомарные операции.

Ниже пример реализации мьютекса на атомарных операциях, если кому интересно. Имхо реализация примитивов синхронизации на ассемблере должна выглядеть примерно так же.

Code (Text):

1. package ru.scf37.todo;
2.  
3. import java.util.ArrayList;
4. import java.util.List;
5. import java.util.concurrent.atomic.AtomicBoolean;
6.  
7. import junit.framework.Assert;
8.  
9. import org.junit.Test;
10.  
11. public class AtomicTest {
12.     private AtomicBoolean atomic = new AtomicBoolean(); //atomic boolean
13.     private Boolean locked = false; //boolean variable(also serves as mutex) to validate locked state.
14.    
15.     @Test
16.     public void testAtomicLock() {
17.         Runnable job = new Runnable() {
18.             @Override
19.             public void run() {
20.                 atomicLock();
21.                 synchronized (locked) { //entering mutex
22.                     Assert.assertFalse(locked); //should be false
23.                     locked = true;
24.                 }
25.                 try {
26.                     Thread.sleep(250);
27.                 } catch (InterruptedException e) {
28.                 }
29.                 synchronized (locked) { //entering mutex
30.                     Assert.assertTrue(locked); //should be still locked
31.                     locked = false;
32.                 }
33.                 atomicUnlock();
34.             }
35.         };
36.         List<Thread> threads = new ArrayList<Thread>();
37.         for (int i = 0 ; i < 25 ; i++) {
38.             Thread thread = new Thread(job);
39.             thread.start();
40.             threads.add(thread);
41.         }
42.         for (Thread t : threads) {
43.             try {
44.                 t.join();
45.             } catch (InterruptedException e) {
46.             }
47.         }
48.     }
49.    
50.     private void atomicLock() {
51.         while (true) {
52.             boolean oldValue = atomic.getAndSet(true);
53.             if (oldValue == true) {
54.                 //oops, it is already locked by someone - wait and try again
55.                 try {
56.                     Thread.sleep(200); //sleeeeep or do something else here....
57.                 } catch (InterruptedException e) {
58.                 }
59.             } else {
60.                 break;
61.             }
62.         }
63.     }
64.    
65.     private void atomicUnlock() {
66.         atomic.set(false);
67.     }
68. }

 

Pavia
Видел, но маловато будет

 

scf
http://www.rsdn.ru/forum/java/3622844.flat.aspx

 

scf

гдето так оно и делается

_lock proc LockAddr, isLock
mov ecx, LockAddr
mov eax, isLock
xchg [ecx], eax
ret
_lock endp

что делать если возвращается признак заблокированности ресурса - ваше дело. можете организовывать буфера (особенно актуально, когда с инетом дело имеешь), можете выполнять другие операции, можете ждать, можете попробовать уточнить обстановку на предмет висяка, например.

разные среды предоставляют разные реализации этих возможностей. дальнейшее поскипано заради покоя

 

wsd
Хорошая штука для самообразования и особенно подготовки к собеседованиям.

НО - самое главное - это книга, которая упоминается в последнем посте.
Maurice Herlihy, Nir Shavit - The Art of Multiprocessor Programming - 2008

Она написана с упором на java, но отдельные главы однозначно будут интересны всем, занимающимся разработкой многопоточных/асинхронных приложений.

 

qqwe
А разве префикс LOCK не нужен перед xchg?

 

scf
xchg атомарная команда. Поэтому префикс LOCK ненужен.

 

ещё есть инструкция xadd.

 

t00x
Перед xadd надо добавлять префикс LOCK.
Ровно как и перед другими. Но так в процессоре полно команд которые можно использовать вместе с LOCK. Для решения проблем синхронизации.