Re[12]: Влад, что смешного?
От: Mazay Россия  
Дата: 14.10.06 18:27
Оценка:
Здравствуйте, IT, Вы писали:

IT>Давай на примерах. Допустим у нас есть простая форма с двумя TextBoxes и одной кнопкой. По кнопке запускается длительный процесс, который в качестве параметра берёт текст из первого бокса, а результат помещает во второй.


Первый вариант понятен

IT>
IT>string    _text;
IT>string    _result;
IT>Exception _exception;
IT>WaitForm  _waitForm;

IT>void button1_Click2(object sender, EventArgs e)
IT>{
IT>    _text     = textBox1.Text;
IT>    _waitForm = new WaitForm();

IT>    new Thread(LongProcessThread).Start();

IT>    _waitForm.ShowDialog();
IT>}

IT>void LongProcessThread()
IT>{
IT>    try
IT>    {
IT>        _exception = null;
IT>        _result    = LongProcess(_text);
IT>    }
IT>    catch (Exception ex)
IT>    {
IT>        _exception = ex;
IT>    }

IT>    Invoke(AfterLongProcess);
IT>}
IT>

Просвятите пожалуйста про Invoke(): метод AfterLongProcess() выполнится в потоке UI (там где button1_Click2 отработал) или в вызванном потоке? Наверное всё-таки в UI иначе зачем огород городить. Почему нельзя здесь же кинуть MessageBox об исключении? Или это просто для сигнализации о том что в _result невалидная информация?
IT>
IT>void AfterLongProcess()
IT>{
IT>    _waitForm.Close();

IT>    if (_exception == null)
IT>        textBox2.Text = _result;
IT>    else
IT>        MessageBox.Show(_exception.Message);
IT>}
IT>


Совковая лопата опущена

IT>А теперь пофантазируем, что мог быть сделать катарпиллер. Допустим, у нас имелась бы возможность сказать компилятору, например, с помощью атрибутов, что доступ к объектам наследникам класса Control может осуществлятся только из потока UI. Предположим также, что у нас есть некая языковая конструкция, которая указывает компилятору, что определённая часть кода должна выполняться в новом потоке. Вот как мог бы выглядеть гипотетический код:


IT>
IT>void button1_Click1(object sender, EventArgs e)
IT>{
IT>    WaitForm waitForm = new WaitForm();

IT>    newthread
IT>    {
IT>        try
IT>        {
IT>            textBox2.Text = LongProcess(textBox1.Text);
IT>            waitForm.Close();
IT>        }
IT>        catch (Exception ex)
IT>        {
IT>            waitForm.Close();
IT>            MessageBox.Show(ex.Message);
IT>        }
IT>    }

IT>    waitForm.ShowDialog();
IT>}
IT>


textBox2.Text = LongProcess(textBox1.Text); — это в каком потоке выполняется? А если в это время из основного потока что-нить сюда запишут? Ах да, "доступ к объектам наследникам класса Control может осуществлятся только из потока UI", а тогда что-за поток мы создали в newthread ? В этом же новом потоке мы легко закрываем waitForm. А что тогда мешало нам сделать это в LongProcessThread() ? И сообщение об исключении там же кинуть.
Кстати newthread вызывается до waitForm.ShowDialog() ? А если он и отработает раньше и waitForm.Close() вызовет раньше ?

В целом я согласен с Вами, что в рационе современных языков (C++/C#/Java) явно не хватает "синтаксического сахара" для удобства многопоточного программирования, но переходить из-за этого на функциональщину — увольте. Функциональный язык на обычных компьютерах это насилие и извращение, ибо процессор-то всё равно работает линейно и понятие состояния тоже имеется. Возможно для более высокоуровнего программирования это и найдёт своё применение, а так —
А какой код буде легче читаться/писаться/думаться — функциональный или обычный обвешанный мютексами — это отдельный вопрос и явно не имеющий очевидного ответа.
Главное гармония ...
Re[24]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 14.10.06 18:39
Оценка: +1 :)
VladD2 wrote:
> C>Во-первых, никто не мешает запустить ДВЕ копии интерпретатора Эрланга,
> C>на разных процессорах и связать их как угодно (в том числе копии могут
> C>быть на других машинах). Это УЖЕ работает.
> Толку то? Еще раз, последний, сама ОС не повзволят использовать 80
> процессоров одновременно. Больше я на подобные вопрсы не отвечаю.
Слив засчитан.

http://www.sgi.com/products/servers/altix/4000/

SGI Altix 4700 incorporates the shared-memory NUMAflex™ architecture,
which simplifies software development, workload management and system
administration. It supports up to 512 processors under one instance
of Linux
and as much as 128TB of globally shared memory. Supporting
these powerful capabilities is the NUMAlink™ interconnect, which leads
the industry in bandwidth and latency for superior performance on
cluster applications. The SGI Altix 4700 represents a versatile solution
for shared or distributed memory applications of any scale.


Sun Niagara вполне себе неплохо живет с 32 ядрами.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[13]: Влад, что смешного?
От: IT Россия linq2db.com
Дата: 14.10.06 21:59
Оценка:
Здравствуйте, Mazay, Вы писали:

M>Просвятите пожалуйста про Invoke():


Invoke выглядит примерно так:

public delegate void InvokeDelegate();

public void Invoke(InvokeDelegate call)
{
    if (InvokeRequired)
        base.Invoke(call);
    else
        call();
}


M>метод AfterLongProcess() выполнится в потоке UI (там где button1_Click2 отработал) или в вызванном потоке? Наверное всё-таки в UI иначе зачем огород городить.


Точно.

M>Почему нельзя здесь же кинуть MessageBox об исключении?


Потому что MessageBox — это тоже UI.

M>Совковая лопата опущена


Ы?

M>textBox2.Text = LongProcess(textBox1.Text); — это в каком потоке выполняется? А если в это время из основного потока что-нить сюда запишут? Ах да, "доступ к объектам наследникам класса Control может осуществлятся только из потока UI",


Мне нравится как ты сам себе задаёшь вопросы и сам же на них отвечаешь

M>а тогда что-за поток мы создали в newthread ?


New thread.

M>В этом же новом потоке мы легко закрываем waitForm.


Внимательно почитай моё сообщение. Ты пытаешься найти что-то неправильное в гипотетическом коде, говорить о котом я начал со слов "А теперь пофантазируем".

M>В целом я согласен с Вами, что в рационе современных языков (C++/C#/Java) явно не хватает "синтаксического сахара" для удобства многопоточного программирования, но переходить из-за этого на функциональщину — увольте. Функциональный язык на обычных компьютерах это насилие и извращение, ибо процессор-то всё равно работает линейно и понятие состояния тоже имеется.


Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.

M> Возможно для более высокоуровнего программирования это и найдёт своё применение, а так —




M> А какой код буде легче читаться/писаться/думаться — функциональный или обычный обвешанный мютексами — это отдельный вопрос и явно не имеющий очевидного ответа.


Мьютексы то тут причём?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Влад, что смешного?
От: Mazay Россия  
Дата: 15.10.06 12:48
Оценка:
Здравствуйте, IT, Вы писали:

M>>Почему нельзя здесь же кинуть MessageBox об исключении?

IT>Потому что MessageBox — это тоже UI.
А в последнем "гипотетичеком" варианте этот самый UI вызывается вовсе не в UI'шном потоке.

M>>Совковая лопата опущена

IT>Ы?
Это я про вариант с замыканиями.

IT>Ты пытаешься найти что-то неправильное в гипотетическом коде, говорить о котом я начал со слов "А теперь пофантазируем".

Я хочу сказать что очень сомневаюсь в полезности этих гипотетических возможностей компилятора:

Допустим, у нас имелась бы возможность сказать компилятору, например, с помощью атрибутов, что доступ к объектам наследникам класса Control может осуществлятся только из потока UI. Предположим также, что у нас есть некая языковая конструкция, которая указывает компилятору, что определённая часть кода должна выполняться в новом потоке.

Если уж фантазировать, до давайте делать это пореалистичнее. А то пример совсем неубедительный получился.

M>>В целом я согласен с Вами, что в рационе современных языков (C++/C#/Java) явно не хватает "синтаксического сахара" для удобства многопоточного программирования, но переходить из-за этого на функциональщину — увольте. Функциональный язык на обычных компьютерах это насилие и извращение, ибо процессор-то всё равно работает линейно и понятие состояния тоже имеется.


IT>Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.


Я имел ввиду вот это:

В функциональном программировании переменные – это просто псевдонимы для выражений (так что нам необязательно записывать всё в одну строчку). Они (переменные) не могут быть изменены. Все переменные могут принимать значения только один раз.

(это из статьи "Функциональное программирование для всех")
,а Влад выше писал:

Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.



M>> А какой код буде легче читаться/писаться/думаться — функциональный или обычный обвешанный мютексами — это отдельный вопрос и явно не имеющий очевидного ответа.


IT>Мьютексы то тут причём?


При том, что ими можно проблемы, которые в гипотетическом коде предлагалось решать с помощью атрибутов.
Главное гармония ...
Re[15]: Влад, что смешного?
От: IT Россия linq2db.com
Дата: 15.10.06 15:32
Оценка: +1
Здравствуйте, Mazay, Вы писали:

M>А в последнем "гипотетичеком" варианте этот самый UI вызывается вовсе не в UI'шном потоке.


Так почитай внимательно первый же абзац после этого примера. А то создаётся впечатление, что ты только картинки посмотрел.

IT>>Ты пытаешься найти что-то неправильное в гипотетическом коде, говорить о котом я начал со слов "А теперь пофантазируем".


M> Если уж фантазировать, до давайте делать это пореалистичнее. А то пример совсем неубедительный получился.


Видишь ли, я не предлагал законченного решения, которое уже можно было бы начинать обсуждать. Я лишь указал направление. Если хочешь пофантазировать, то начинай фантазировать, а не критиковать то, чего пока ещё не существует.

IT>>Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.


M>Я имел ввиду вот это:

M>

M>В функциональном программировании переменные – это просто псевдонимы для выражений (так что нам необязательно записывать всё в одну строчку). Они (переменные) не могут быть изменены. Все переменные могут принимать значения только один раз.

(это из статьи "Функциональное программирование для всех")


Это и есть догмы.

M>,а Влад выше писал:

M>

M>Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.


И что здесь не так?

IT>>Мьютексы то тут причём?


M>При том, что ими можно проблемы, которые в гипотетическом коде предлагалось решать с помощью атрибутов.


В гипотетическом коде предлагается совсем другое. А именно — приведение многопоточного алгоритма к линейному виду.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Многопоточность, параллелизм
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.10.06 22:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Слив засчитан.


Как дети право. Страна не пуганых идиотов... (с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 16.10.06 04:18
Оценка: +1 :)
VladD2 wrote:
> C>Слив засчитан.
> Как дети право. Страна не пуганых идиотов... (с)
Ну так а что еще в этом форуме делать?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[23]: Многопоточность, параллелизм
От: Gaperton http://gaperton.livejournal.com
Дата: 16.10.06 13:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Gaperton wrote:

>> C>SMP для 80 ядер вряд ли будет возможен — так как доступ к памяти станет
>> C>больным местом. Значит как-то надо эти ядра делить на кластеры, которые
>> C>будут взаимодействовать только через каналы связи.
>> Ну, внутри все будет так, как ты говоришь. А снаружи, с точки зрения
>> софта, это скорее всего будет выглядеть как SMP.
>> Пример — два двухъядерных процессора Opteron. Ядра не равноправны — в
>> рамках одного кристалла они разделяют кэш. К соседнему кристаллу лезут
>> через HyperThreading. И ничего — все равно это выглядит для софта как
>> SMP, потому как это проще программить. И ничего.
C>Понимаешь, для двух процессоров это прокатит — так как достаточно редкие
C>обращения к общей памяти не будут делать погоды. А вот для 80
C>процессоров — уже не уверен, нужно уже что-то другое.

Cyberax, все уже украдено до нас. Я тебе уже письма три как объясняю, что SMP не подразумевает наличия физически общей памяти. Что общая память — это удобная абстракция, которая выражается через message-passing. Могу только добавить, что в рамках модели общей памяти уже сейчас работает софт на суперкомпьютерных кластерах с тысячами узлов, связанных средой Merynet или Infiniband (у которых с латентностью не ахти — внутри кристалла будет существенно лучше).

О проблеме, о которой ты говоришь, все давно уже подумали. В очередной раз советую почитать про архитектуру ccNUMA (cache coherent non-uniform memory access), на алгоритм синхронизации кэшей в рамках которого уже даже стандарт IEEE принят.
Re[9]: Многопоточность, параллелизм
От: Gaperton http://gaperton.livejournal.com
Дата: 16.10.06 13:22
Оценка: 11 (1) +1 :))
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:


G>>Эта мода (VLIW, в случае Itanium) — уже в прошлом. У такой архитектуры есть ряд недостатков, один из которых связан, например, с тем, что широкий VLIW плохо кладется на кристалл — у него широкие шины. Это раздувает кристалл, делая его дороже, и снижает тактовые частоты из-за длинных связей. Например, пресловутый E2K, о котором много говорили, работает на практике (а не на бумаге) на частоте 300 МГц.


VD>Нет в природе никакого E2K.


Он в настоящий момент проходит государственные испытания, и в ближайшее время будет принят на вооружение. Дизайн в собственности МО РФ (которое и финансировало разработку), на открытый рынок продаваться не будет. Твои соображения по поводу чип-дизайна конечно очень любопытны, особенно где ты со знанием дела пишешь про проблемы с производственной и инженерной базой, но извини, я их поскипал. Исключительно из скромности. Где мне в такой мощной философской дискуссии участвовать, когда такие зубры чипостроения в бой пошли .
Re[24]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 16.10.06 13:26
Оценка:
Gaperton wrote:
> Cyberax, все уже украдено до нас. Я тебе уже письма три как объясняю,
> что SMP не подразумевает наличия физически общей памяти. Что общая
> память — это удобная абстракция, которая выражается через
> message-passing. Могу только добавить, что в рамках модели общей памяти
> уже сейчас работает софт на суперкомпьютерных кластерах с тысячами
> узлов, связанных средой Merynet или Infiniband (у которых с латентностью
> не ахти — внутри кристалла будет существенно лучше).
Я знаю про это. Мне интересно как это можно более эффективно сделать.

> О проблеме, о которой ты говоришь, все давно уже подумали. В очередной

> раз советую почитать про архитектуру ccNUMA (cache coherent non-uniform
> memory access), на алгоритм синхронизации кэшей в рамках которого уже
> даже стандарт IEEE принят.
Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна,
выражается в виде возможности указать для страниц памяти их "удаленность".
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[25]: Многопоточность, параллелизм
От: Gaperton http://gaperton.livejournal.com
Дата: 16.10.06 13:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> О проблеме, о которой ты говоришь, все давно уже подумали. В очередной

>> раз советую почитать про архитектуру ccNUMA (cache coherent non-uniform
>> memory access), на алгоритм синхронизации кэшей в рамках которого уже
>> даже стандарт IEEE принят.
C>Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна,
C>выражается в виде возможности указать для страниц памяти их "удаленность".

Я тебе уже писал. Это делается в железе. В Оптеронах это сделано на уровне протокола Hypertransport. Никакой особой поддержки в линуксе для этого не нужно. Так что вам, программерам, беспокоиться особенно не о чем .
Re[26]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 16.10.06 13:41
Оценка:
Gaperton wrote:
> C>Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна,
> C>выражается в виде возможности указать для страниц памяти их "удаленность".
> Я тебе уже писал. Это делается *в железе*. В Оптеронах это сделано на
> уровне протокола Hypertransport. Никакой особой поддержки в линуксе для
> этого не нужно. Так что вам, программерам, беспокоиться особенно не о чем .
А теперь ты прочитай про nccNUMA
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[27]: Многопоточность, параллелизм
От: Gaperton http://gaperton.livejournal.com
Дата: 16.10.06 14:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Gaperton wrote:

>> C>Ну и? В том же Линуксе или Windows поддержка для NUMA минимальна,
>> C>выражается в виде возможности указать для страниц памяти их "удаленность".
>> Я тебе уже писал. Это делается *в железе*. В Оптеронах это сделано на
>> уровне протокола Hypertransport. Никакой особой поддержки в линуксе для
>> этого не нужно. Так что вам, программерам, беспокоиться особенно не о чем .
C>А теперь ты прочитай про nccNUMA

http://en.wikipedia.org/wiki/CcNUMA

А теперь ты мне дай сцылку на nccNUMA . С удовольствием почитаю.
Re[28]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 16.10.06 15:27
Оценка:
Gaperton wrote:
>> > Я тебе уже писал. Это делается *в железе*. В Оптеронах это сделано на
>> > уровне протокола Hypertransport. Никакой особой поддержки в линуксе для
>> > этого не нужно. Так что вам, программерам, беспокоиться особенно не о
> чем .
> C>А теперь ты прочитай про nccNUMA
> http://en.wikipedia.org/wiki/CcNUMA
> А теперь ты мне дай сцылку на nccNUMA . С удовольствием почитаю.
Вот найти бы их еще, я читал про них в бумажных журналах и статьях на ACM.

Если вкратце, то в nccNUMA за синхронностью кэша должны следить сами
приложения, явно выставляя специальные барьерные инструкции для
синхронизации с общей памятью (когда это необходимо). Это позволяет
легко сделать "транзакционную память" (тут Курилка, кажется, об этом
линк присылал), свести к минимуму простои из-за синхронизации и т.п.

Самой известной из таких систем, пожалуй, является Cray T3E, в который
втыкалось примерно 2000 процессорных элементов (с двумя процессорами в
каждом).

Такие архитектуры пока не имеют распространения из-за сложности
программирования, но наверняка станут более популярными с ростом числа
процессоров.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[29]: Многопоточность, параллелизм
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.10.06 06:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Если вкратце, то в nccNUMA за синхронностью кэша должны следить сами

C>приложения, явно выставляя специальные барьерные инструкции для
C>синхронизации с общей памятью (когда это необходимо). Это позволяет
C>легко сделать "транзакционную память" (тут Курилка, кажется, об этом
C>линк присылал), свести к минимуму простои из-за синхронизации и т.п.

Объясни мне, разве не такая модель памяти и используется в java & .net?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[30]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 17.10.06 08:33
Оценка:
Andrei N.Sobchuck wrote:
> C>Если вкратце, то в nccNUMA за синхронностью кэша должны следить сами
> C>приложения, явно выставляя специальные барьерные инструкции для
> C>синхронизации с общей памятью (когда это необходимо). Это позволяет
> C>легко сделать "транзакционную память" (тут Курилка, кажется, об этом
> C>линк присылал), свести к минимуму простои из-за синхронизации и т.п.
> Объясни мне, разве не такая модель памяти и используется в java & .net?
В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не
может использоваться на nccNUMA).

В Java сейчас модель памяти, совместимая с nccNUMA (поэтому там не
работает Double-Check Locking).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[31]: Многопоточность, параллелизм
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.10.06 13:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не

C>может использоваться на nccNUMA).

То есть в .net вся память рассматривается как volatile (в java)?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[32]: Многопоточность, параллелизм
От: Cyberax Марс  
Дата: 17.10.06 15:05
Оценка:
Andrei N.Sobchuck wrote:
> C>В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не
> C>может использоваться на nccNUMA).
> То есть в .net вся память рассматривается как volatile (в java)?
Да, для x86 и ccNUMA это будет работать, так как гарантируется
когерентность кэшей.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Многопоточность, параллелизм
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.10.06 15:47
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

G>Он в настоящий момент проходит государственные испытания,


"Он" называется не Е2К, а Эльбрус <b>Е3М</b>.

G> и в ближайшее время будет принят на вооружение. Дизайн в собственности МО РФ (которое и финансировало разработку), на открытый рынок продаваться не будет. Твои соображения по поводу чип-дизайна конечно очень любопытны, особенно где ты со знанием дела пишешь про проблемы с производственной и инженерной базой, но извини, я их поскипал.


Ничего, ничего. Мне простительно. Я все же не работаю в конторе разнабатывающей чипы. А вот то что ты не знаешь название чипа о котором говоришь — это немного странно.

G> Исключительно из скромности. Где мне в такой мощной философской дискуссии участвовать, когда такие зубры чипостроения в бой пошли .


Начал в себе скромность воспитывать? Это похвально.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Многопоточность, параллелизм
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.10.06 06:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>В .NET — нет, там более сильная модель (поэтому .NET, вообще говоря, не

>> C>может использоваться на nccNUMA).
>> То есть в .net вся память рассматривается как volatile (в java)?
C>Да, для x86 и ccNUMA это будет работать, так как гарантируется
C>когерентность кэшей.

Интересно, а что с mono?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.