.NET имеет реализацию Словаря, которая эквивалентна ConcurrentHashMap Java?
Это может быть. Обратный вызов done() сообщает Jasmine, что вы выполняете асинхронную задачу; Тем не менее, вы должны быть осторожны, чтобы поймать ошибки.
Добавление в done.fail
import axios from "axios";
describe("Some test for ", () => {
beforeEach(function(done) {
axios
.get(
"******************"
)
.then(response => {
data_file = response.data;
done();
})
// if the above fails to .get, then we should catch here and fail with a message
.catch(error => {
done.fail('axios.get failed to execute');
});
});
Лучший подход. Использование async / await
В вашей конфигурации Protractor вам нужно будет добавить SELENIUM_PROMISE_MANAGER: false для включения async / await. Теперь вам потребуется дождаться всех обещаний.
import axios from "axios";
describe("Some test for ", () => {
beforeEach(async () => {
try {
const data_file = await axios.get("******************").data;
} catch (e) {
console.error('axios.get failed to execute');
throw e; // throwing errors should fail the spec.
}
});
it("some spec ", async () => {
// .getText returns a Promise so you'll need to await it
// to get the string value.
expect(await $('#someId').getText()).toBe(data_file.someData);
});
});
4 ответа
Не то, чтобы я знаю о. Самой близкой вещью к тому, что Вы ищете, вероятно, был бы Синхронизированный метод Хеш-таблицы, которая возвращается (вид) ориентированная на многопотоковое исполнение обертка вокруг хеш-таблицы. Это только ориентировано на многопотоковое исполнение для нескольких устройств записи или нескольких средств чтения, все же. Если я вспомню правильно, то смесь устройств записи и средств чтения не будет ориентирована на многопотоковое исполнение.
Править: Это было записано до.NET 4 выпускаемый, когда, очевидно, существует ConcurrentDictionary. Я оставляю его здесь как ссылку для тех, которые нуждаются в.NET 3.5.
Я не знаю ни о каком эквиваленте ConcurrentHashMap.
С точки зрения общих утилит параллелизма-.NET всегда обеспечивала немного больше, чем основы, с точки зрения которых Java раньше обеспечивал, Mutex, ManualResetEvent, AutoResetEvent и ReaderWriterLock; затем позже (.NET 2.0) Semaphore и (.NET 3.5) ReaderWriterLockSlim - а также пул потоков всего процесса, конечно.
Большая встряска произойдет в.NET 4.0, когда Параллельные Расширения прибудут - который должен сделать параллелизм намного более простым. Аналогично Время выполнения Координации и Параллелизма наконец освобождается от кандалов Microsoft Robotics Studio, хотя я не ясен на точно, куда это направилось (будет ли это частью самой.NET или отдельной библиотекой).
Лично, я нахожу, что наличие отдельных методов, столь синхронизируемых обычно, не так полезно, как это звучит.
Обычно Вы могли бы хотеть сделать, связанное "получает" и "поместило" в близкую последовательность, и если другой поток смотрит на те же значения, у Вас есть непосредственная гонка потока. Аналогично (в зависимости от сценария) Вы не хотите кого-то читающего значения, что Вы продолжаете работать.
Для широкого подхода, просто с помощью внешнего Monitor (lock(...) может работать хорошо на многие ситуации. Это просто, легко, и если Вы не являетесь объектом тяжелой загрузки потока, более, чем соответствующей.
Для более сложных сценариев, вещей как ReaderWriterLockSlim и т.д. более гибки. Но я запустил бы простой, и только изменил бы вещи при профилировании шоу существует подлинная состязательная проблема.
Как примечания Jon, с Параллельным Расширением прибывает, совершенно новое убило высокопроизводительных устройств синхронизации; от того, что я вижу (например, здесь, здесь и здесь), это - часть.NET 4.0
Входящий .Net 4.0 имеет класс ConcurrentDictionary, удобный метод GetOrAdd.
public TValue GetOrAdd(
TKey key,
Func<TKey, TValue> valueFactory
)
Очень полезен для глобальных серверных кэшей.