Хочется странного
Есть кроссплатформенные языки типа Java. Но они все как назло - интерпретаторы.
Есть кроссплатформенные библиотеки к компиляторам. Но они все как назло - не стандарт языка.
А хочется странного. Хочется, чтобы многие вещи стали стандартом для компилируемого языка. Хочется языка типа C++, но с кое-какими изменениями. Могу я ведь помечтать, а? :)
Я напишу только один пункт моих "мечт".
1. Хочу, чтобы были стандартные средства работы с thread-ами - мутексы, треды, сигналы... Причем, даже не в форме библиотек, а в форме ключевых слов, дополнительных конструкций языка.
Например:
int a, b, c;
mutex x for a, b;
- чтобы компилятор завел мутекс x и использовал его сам, автоматически при обращениях к переменным a, b. Чтобы компилятор сам оптимизировал это дело. Например вот для такой серии:
a++;
c = 4;
b-= 2;
- хороший компилятор должен "понять", что хотя переменная c и не требует защиты мутексом, но присвоение занимает мало времени, а потому весь фрагмент лучше обрамить одной парой x.lock ... x.unlock.
Далее, чтобы компилятор снял с программиста заботу о разблокировании мутексов при передаче управления (исключения, return и т.п.)
Треды тоже... каждая операционка кто во что горазд. Надо единую хрень, встроенную в йезыг. Как-то так:
void myfunc(int x, char *y)
{
...
}
- Это просто функция. Параметры произвольные.
А потом так:
thread t= myfunc(99, "Loading...");
или так:
thread myfunc(99, "Loading...");
- то есть, чтобы произвольную функцию можно было средствами самого языка вызвать в отдельном треде как тред. И передать треду параметры не через жопу, а просто как параметры функции. В первом варианте синтаксиса еще и вернуть идентификатор треда.
Опционально чтобы у типа thread был какой-то разумный набор операций (suspend/resume/kill...). Как минимум - сравнение тредов, узнавание id текущего треда (ключевое слово thread.this ), узнавание id треда, который создал этот тред (ключевое слово thread.parent ).
Ну и, наконец, к тредам добавить средства синхронизации и передачи данных между тредами. Что-нибудь вроде такого:
Пояснения. Надо, чтобы содержимое любой переменной можно было отослать в другой тред. Как только тот тред доходит до нужного места, он забирает "подарочек". Если подарка еще нет, тот тред ждет. Отсылающий тред ничего не ждет, содержимое переменной копируется в скрытый буфер. Если не хочется копировать много данных, то отсылаем указатель.
...
class MyData
{
int a;
char *c;
};
...
MyData b;
MyData result;
...
thread t = myfunc(99, "Loading...");
...
b.a= 1; //заполняем данные в "подарке"
b >> t; /*отсылаем "подарок", какие-то дополнительные данные, которые
на момент вызова myfunc еще не были готовы */
...
result << t; //забираем результаты исполнения треда, ждем если надо
void myfunc(int x, char *y)
{
...
MyData b;
MyData result;
...
//берем какие-то дополнительные параметры
b << thread.parent; /* thread.parent - ключевое слово, означает тред, который создал этот тред */
...
//отсылаем результаты
result >> thread.parent;
}
Помечтаем, а? :)
Есть кроссплатформенные библиотеки к компиляторам. Но они все как назло - не стандарт языка.
А хочется странного. Хочется, чтобы многие вещи стали стандартом для компилируемого языка. Хочется языка типа C++, но с кое-какими изменениями. Могу я ведь помечтать, а? :)
Я напишу только один пункт моих "мечт".
1. Хочу, чтобы были стандартные средства работы с thread-ами - мутексы, треды, сигналы... Причем, даже не в форме библиотек, а в форме ключевых слов, дополнительных конструкций языка.
Например:
int a, b, c;
mutex x for a, b;
- чтобы компилятор завел мутекс x и использовал его сам, автоматически при обращениях к переменным a, b. Чтобы компилятор сам оптимизировал это дело. Например вот для такой серии:
a++;
c = 4;
b-= 2;
- хороший компилятор должен "понять", что хотя переменная c и не требует защиты мутексом, но присвоение занимает мало времени, а потому весь фрагмент лучше обрамить одной парой x.lock ... x.unlock.
Далее, чтобы компилятор снял с программиста заботу о разблокировании мутексов при передаче управления (исключения, return и т.п.)
Треды тоже... каждая операционка кто во что горазд. Надо единую хрень, встроенную в йезыг. Как-то так:
void myfunc(int x, char *y)
{
...
}
- Это просто функция. Параметры произвольные.
А потом так:
thread t= myfunc(99, "Loading...");
или так:
thread myfunc(99, "Loading...");
- то есть, чтобы произвольную функцию можно было средствами самого языка вызвать в отдельном треде как тред. И передать треду параметры не через жопу, а просто как параметры функции. В первом варианте синтаксиса еще и вернуть идентификатор треда.
Опционально чтобы у типа thread был какой-то разумный набор операций (suspend/resume/kill...). Как минимум - сравнение тредов, узнавание id текущего треда (ключевое слово thread.this ), узнавание id треда, который создал этот тред (ключевое слово thread.parent ).
Ну и, наконец, к тредам добавить средства синхронизации и передачи данных между тредами. Что-нибудь вроде такого:
Пояснения. Надо, чтобы содержимое любой переменной можно было отослать в другой тред. Как только тот тред доходит до нужного места, он забирает "подарочек". Если подарка еще нет, тот тред ждет. Отсылающий тред ничего не ждет, содержимое переменной копируется в скрытый буфер. Если не хочется копировать много данных, то отсылаем указатель.
...
class MyData
{
int a;
char *c;
};
...
MyData b;
MyData result;
...
thread t = myfunc(99, "Loading...");
...
b.a= 1; //заполняем данные в "подарке"
b >> t; /*отсылаем "подарок", какие-то дополнительные данные, которые
на момент вызова myfunc еще не были готовы */
...
result << t; //забираем результаты исполнения треда, ждем если надо
void myfunc(int x, char *y)
{
...
MyData b;
MyData result;
...
//берем какие-то дополнительные параметры
b << thread.parent; /* thread.parent - ключевое слово, означает тред, который создал этот тред */
...
//отсылаем результаты
result >> thread.parent;
}
Помечтаем, а? :)
no subject
no subject
no subject
no subject
так же, например, и массивы - объекты и класс. просто компилер знает, что это за типы, они намертво встроены в среду, поэтому работу в ними он компилит не в "обращения к методам", а в нормальный пацанский машинный код по месту.
С тредами там такая же тема - они жестко встроены в виртуальную машину, компилятор знает о них. Тот факт, что для красивости и единообразия есть класс System.Threading.Thread, ровным счетом ничего не меняет и никак не отражается на производительности или "встроенности".