Ориентированный на многопотоковое исполнение ContainsKey
Лучше всего использовать регулярные выражения. Строки являются неизменяемыми, что означает, что вы не можете их изменить - вам нужно переписать всю строку - чтобы сделать это оптимальным образом, вы должны использовать класс StringBuilder и Append каждый символ, который вы хотите.
Также следите за вашим кодом - char.IsNumber проверяет не только символы 0 - 9, он также возвращает true для каждого числового символа, такого как ٢, и вы, вероятно, этого не хотите.
вот полный список символов, возвращающих true:
0123456789٠١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹߀߁߂߃߄߅߆߇߈߉०१२३४५६७८९০১২৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫૬૭૮૯୦୧୨୩୪୫୬୭୮୯௦௧௨௩௪௫௬௭௮௯౦౧౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯๐๑๒๓๔๕๖๗๘๙໐໑໒໓໔໕໖໗໘໙༠༡༢༣༤༥༦༧༨༩၀၁၂၃၄၅၆၇၈၉႐႑႒႓႔႕႖႗႘႙០១២៣៤៥៦៧៨៩᠐᠑᠒᠓᠔᠕᠖᠗᠘᠙᥆᥇᥈᥉᥊᥋᥌᥍᥎᥏᧐᧑᧒᧓᧔᧕᧖᧗᧘᧙᭐᭑᭒᭓᭔᭕᭖᭗᭘᭙᮰᮱᮲᮳᮴᮵᮶᮷᮸᮹᱀᱁᱂᱃᱄᱅᱆᱇᱈᱉᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙꘠꘡꘢꘣꘤꘥꘦꘧꘨꘩꣐꣑꣒꣓꣔꣕꣖꣗꣘꣙꤀꤁꤂꤃꤄꤅꤆꤇꤈꤉꩐꩑꩒꩓꩔꩕꩖꩗꩘꩙０１２３４５６７８９
, вы также должны использовать [0-9], а не \d в своих регулярных выражениях, если вы хотите использовать только анализируемые цифры.
Вы также можете использовать трюк для .Split вашей строки на вашем персонаже, а затем .Join ее обратно. Это позволяет не только удалить один или несколько символов, но и заменить его другим символом. Я использую этот трюк для удаления неправильных символов из имени файла:
string.Join("-", possiblyIncorrectFileName.Split(Path.GetInvalidFileNameChars()))
этот код заменит любой символ, который нельзя использовать в действительном имени файла для -
5 ответов
Свойственная потокобезопасность ContainsKey не имеет значения, так как нет никакой синхронизации между ContainsKey и кэшем [ключ].
Например:
if (cache.ContainsKey(key))
// Switch to another thread, which deletes the key.
return cache[key];
MSDN является довольно четким по этому вопросу:
Чтобы позволить набору быть полученным доступ несколькими потоками для чтения и записи, необходимо реализовать собственную синхронизацию.
Для большего количества информации JaredPar отправил замечательную запись в блоге по http://blogs.msdn.com/jaredpar/archive/2009/02/11/why-are-thread-safe-collections-so-hard.aspx на ориентированных на многопотоковое исполнение наборах.
Нет, ContainsKey не ориентирован на многопотоковое исполнение, если Вы пишете значения, в то время как Вы пытаетесь читать.
Да, существует шанс, Вы могли возвратить недопустимые результаты - но Вы, вероятно, начнете видеть исключения сначала.
Смотрите на ReaderWriterLockSlim для привязки таких ситуаций - это создается, чтобы сделать этот вид материала.
Вот то, что это говорит в документации MSDN:
Общедоступные помехи (Совместно использованный в Visual Basic) члены этого типа ориентированы на многопотоковое исполнение. Любые члены экземпляра, как гарантируют, не будут ориентированы на многопотоковое исполнение.
Словарь <(<(TKey, TValue>)>) может поддерживать несколько читателей одновременно, пока набор не изменяется. Несмотря на это, перечисление через набор является внутренне не ориентированной на многопотоковое исполнение процедурой. В редком случае, где перечисление борется с доступом для записи, набор должен быть заблокирован во время всего перечисления. Чтобы позволить набору быть полученным доступ несколькими потоками для чтения и записи, необходимо реализовать собственную синхронизацию.
Если я читаю, что правильно, не полагаю, что это ориентировано на многопотоковое исполнение.
Словарь не Ориентирован на многопотоковое исполнение.
Если Вы говорите это
что происходит, если тот метод выполняется, когда другой поток добавляет что-то к словарю?
затем я предполагаю, что другие функции получают доступ cache также. Необходимо синхронизировать доступы (чтение и запись) к cache. Используйте свой объект блокирования во всех этих операциях.
Я верю не ориентированному на многопотоковое исполнение,
Я предложил бы, проходят ссылку ниже, она показывает реализацию ориентированного на многопотоковое исполнение словаря или лучше для разработки собственной синхронизации.