2014-09-26 5 views
1

У меня есть эта путаница на какое-то время, являются потоками реализации статического метода, методы экземпляров, безусловно, являются потокобезопасными, если мы назначаем отдельный экземпляр для каждого потока, тогда они не лезьте, потом я понял, что безопасность потоков больше о типах тогда методов, которые сами по себе не выделение памяти, поэтому давайте рассмотрим пример:Статические или нестатические методы, безопасность потоков для типов не методов

private static ConcurrentDictionary<int,int> cd; 

public static void Method1(int userid) 
{ 
    // Modify static object cd based on userid key 
} 

public void Method2(int userid) 
{ 
    // Modify static object cd based on userid key 
} 

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

+1

Когда вы голосуете, объясните причину, что не так с вопросом. У всех нет сомнений. Остановите это молчаливое голосование, по крайней мере, выскажите свое мнение, это довольно случайный и неуважительный –

+0

(а не downvoter) Это не очень пример. Ни один метод не всегда будет потокобезопасным, «статическим» или нет. В комментарии говорится modifiy 'cd', но' cd' является самим ThreadSafe 'ConcurrentDictionary', поэтому все в порядке. – weston

+0

@weston Вот почему я изменяю тип внутри, статический ConcurrentDictionary, вместо этого для метода, отличного от экземпляра, я могу сделать это для словаря до момента, когда я сохраняю его уникальным для потока, но это не может работать для статического метода , поэтому аналогичный код для обоих, изменяя статический тип экземпляров –

ответ

2

ли статические методы реализации потоки безопасны?

Нет, если они изменяют общие данные, то они точно так же небезопасны. Ваш пример может быть в порядке, но только потому, что совместно используемые данные представляют собой потокобезопасность, являющуюся ConcurrentDictionary неизменяемых типов (int).

методы экземпляра, конечно, поточно, если назначить отдельный экземпляр для каждого потока

Ну нет, если экземпляр доступен в одном потоке, то, что не делает его THREADSAFE. Это просто избегает многопоточных проблем.

Короче говоря, static не имеет никакого отношения к многопоточности.

+0

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

+0

Ну, я не знаю о части «все еще выполняю работу». Поскольку вы не можете добиться того же, что и в случаях и статике. – weston

+0

То, что я имею в виду в моем сценарии, где мои типы находятся за веб-api, извлекает json для пользовательского интерфейса, я сохраняю все экземпляры экземпляров объектов бизнес-уровня, чтобы сделать вызов DAL, получить данные и отправить ответ, BL не поддерживать любой объект внутри, поэтому метод экземпляра работает нормально. Для хранения данных мне приходилось либо кэшировать их, либо создавать статические объекты.Теперь я создаю в кеше памяти для повышения производительности, которые будут статичными для хранения данных и будут по-прежнему изменяться в методах экземпляра, в то время как выполняется вызов. Надеюсь, это дает краткий взгляд на случай, о котором я говорю. –

2

Thread Safety не имеет ничего общего с классами и примерами классов. Оба они могут использоваться небезопасно для нарезания резьбы.

Но обычные объекты, такие как элементы управления winforms, не могут получить доступ к своим ресурсам из других потоков, поэтому они проверяют, обращаются ли вы к ним из другого потока, и вы должны убедиться, что используете Invoke для использования нужного потока для этого элемента управления ...

+0

Согласовано, но это очень специфический сценарий для пользовательского интерфейса, созданного Winforms, который обычно нуждается в BackgroundWorker для безопасного доступа к тому же потоку, который содержит/инициировал объект класса winform. –

+0

Нет, нет , это сами элементы управления, которые обрабатывают материал доступа к пользовательскому интерфейсу, фоновый работник может использовать только методы элемента управления, которые являются нейтральными по отношению к потоку ... или другим, если рабочий работает в том же потоке, что и элемент управления (что очень неправильно: -)) – Schwarzie2478

+0

Я думаю, что мой комментарий передает неправильное сообщение. Я имею в виду, что BackgroundWorker может помочь получить доступ к обновлению данных управления потоковым безопасным способом. Это Workaorund, конечно, не на той же нити, это полностью победит цель. В любом случае я не имею ничего общего с winforms, поэтому я могу иметь мир, что такая ситуация не будет на моем пути :) –

1
instance methods are certainly thread safe, if we assign a separate instance to each thread 

Да, когда поток создает объект, только эта нить имеет ссылку на объект никакого другого потока не может получить доступ, что объект, и нет синхронизации потоков требуются при вызове методов экземпляра.

Резьбонарезная безопасность не означает синхронизацию

поточно-означает, что данные не будут испорчены, если два поток пытается получить доступ к данным на некоторой time.Thread безопасного также зависит от того, какого типа вы Чтение и запись типа данных, который вписывается в одно слово (int на 32-разрядном процессоре, долгое время на 64-битном процессоре) является потокобезопасным.

Синхронизация - это способ достижения безопасности потоков, но неизменность объектов тоже.

В ответ на ваш вопрос, если, например, ваш поток предоставляет ссылку на объект статическим полем и передает его как аргумент состояния другому методу потока, здесь требуется синхронизация, если потоки могут выполнять одновременный доступ к записи (но не читать - только то, что отличается от доступа на чтение и запись)

Таким образом, если объект (не связанный с методом) (статический или экземпляр), к которому могут одновременно обращаться многие потоки при чтении и записи, должен быть создан поток безопасно.

+0

Ваше первое утверждение не обязательно верно. Если метод экземпляра обращается к изменяемым статическим членам, то из окна выходит «безопасность потока». –

+0

@JimMischel это верно, поскольку статические члены являются специальной областью внутри кучи, называемой High Frequency Heap, и не связаны с экземпляром, но здесь мы предполагаем, что в объекте нет определенного статического члена. –

2

Статические методы не являются потокобезопасными потому что они статичны.

Они потокобезопасны, потому что кто-то сделал их потокобезопасными. Как правило, в среде .NET статические методы являются потокобезопасными , потому что кто-то написал их таким образом.

Вы можете так же легко писать статические элементы, не содержащие потоки, здесь нет никакой магии.

Те же правила, которым вы должны были следовать, чтобы написать потокобезопасный элемент-экземпляр, должны соблюдаться для написания статических элементов, защищенных потоком.

+0

Позвольте мне понять, что вы сказали, путем выполнения deefaukt статических методов в .net спроектирован так, чтобы быть потокобезопасным, хотя есть достаточно возможности для пользователя делать что-то внутри них, что может сделать его небезопасным для нескольких потоков. –

+0

Нет, это неверно. Статические элементы никоим образом не подразумеваются или не имеют ничего общего с безопасностью потоков. То, что статический метод является потокобезопасным, полностью ** определен программистом, который обязательно записывает его поточно-безопасным способом. Другими словами, вы дали причину и следствие назад. * Соглашение * заключается в том, чтобы убедиться, что статические методы являются потокобезопасными. –

Смежные вопросы