С# принципиально не переносится?

Я некоторое время использовал С# и недавно начал работать над добавлением parallelism к моему второму проекту. Итак, согласно Microsoft, читает и записывает в ints, и даже float являются атомарными

Я уверен, что эти требования к настройке на атомарность просто отлично подходят для x86-архитектур. Однако на таких архитектурах, как ARM (у которых может не быть аппаратной поддержки с плавающей запятой), кажется, что эти гарантии будут трудными.

Проблема только более значима из-за того, что "int" всегда 32 бит. Существует много встроенных устройств, которые не могут атомизировать 32-битную запись.

Кажется, это фундаментальная ошибка в С#. Гарантия атомарности этих типов данных не может быть выполнена портативно.

Как эти гарантии на атомарность предназначены для реализации на архитектурах, где нет FPU или 32-разрядных записей?

Ответы

Ответ 1

В отношении "переносимости" есть две проблемы:

  1. Можно ли создать практическую реализацию языка для различных платформ
  2. Ожидается ли, что программа, написанная на языке, будет корректно работать на разных платформах без изменения

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

    Например, много сетевого кода зависит от того, что (на большинстве платформ) unsigned char - восемь бит, а 32-разрядное целое представлено четырьмя символами без знака в восходящей или нисходящей последовательности. Я использовал платформу, где char был 16 бит, sizeof (int) == 1 и sizeof (long) == 2. Автор компилятора мог бы заставить компилятор просто использовать нижние 8 бит каждого адреса или мог бы добавить много дополнительного кода, чтобы запись указателя 'char' сдвинула бы адрес на один бит (сохраняя lsb), прочитайте адрес, обновите верхнюю или нижнюю половину на основе сохраненного адреса lsb и запишите его обратно. Любой из этих подходов позволил бы сетевому коду работать без изменений, но значительно затруднял бы полезность компилятора для других целей.

    Некоторые из гарантий в CLR означают, что реализовать его на любой платформе нецелесообразно с атомным размером операции менее 32 бит. И что? Если микроконтроллеру требуется более нескольких десятков килобайт пространства кода и ОЗУ, разница в стоимости между 8-битными и 32-битными является довольно маленькими. Так как никто не будет запускать какие-либо изменения CLR на части с 32 КБ кода и 4 КБ ОЗУ, кто заботится о том, может ли такой чип удовлетворить свои гарантии.

    Кстати, я думаю, было бы полезно иметь разные уровни функций, определенные в спецификации C; у многих процессоров, например, есть 8-битные символы, которые могут быть собраны в более длинные слова с использованием объединений, и есть много практического кода, который использует это. Было бы хорошо определить стандарты для компиляторов, которые работают с такими вещами. Я также хотел бы видеть больше стандартов на низком уровне системы, делая некоторые улучшения языка доступными для 8-разрядных процессоров. Например, было бы полезно определить перегрузки для функции, которая может принимать 16-разрядное целое число во время выполнения, 8-битную переменную или встроенную расширенную версию с константой. Для часто используемых функций между ними может быть большая разница в эффективности.

Ответ 2

Не слишком сложно гарантировать атомарность с проверками времени выполнения. Несомненно, вы не будете такими же эффективными, как если бы ваша платформа поддерживала атомарные чтения и записи, но это компромисс между платформами.

В нижней строке: С# (основной язык, не считая некоторых API-интерфейсов для платформы) столь же портативен, как Java.

Ответ 3

Будущее произошло вчера, С# фактически портируется на большое количество встроенных ядер..NET Micro Framework - типичный сценарий развертывания. Номера моделей, которые я вижу в качестве собственных целей, - AT91, BF537, CortexM3, LPC22XX, LPC24XX, MC9328, PXA271 и SH2.

Я не знаю точных деталей реализации их набора основных команд, но я уверен, что это все 32-битные ядра, а некоторые из них являются ядрами ARM. Для написания потокового кода для них требуется минимальная гарантия, и атомарные обновления для правильно выровненных слов являются одним из них. Учитывая поддерживаемый список и что 4-байтовые атомные обновления для согласованных слов тривиальны для реализации в 32-разрядном оборудовании, я надеюсь, что все они действительно поддерживают его.

Ответ 4

Для чего предназначена CLI. Я сомневаюсь, что они подтвердят реализацию, если она не соответствует требованиям. Таким образом, С# переносится на любую платформу, в которой есть.

Ответ 5

Чрезмерно ослабляющие гарантии ради переносимости наносят ущерб мобильности. Чем сильнее гарантии, тем ценнее переносимость. Цель состоит в том, чтобы найти правильный баланс между тем, какие вероятные целевые платформы могут эффективно поддерживать с гарантиями, которые будут наиболее полезными для разработки.