настройка / получение присвоения атомарности [дубликат]
я буду бросать, так как ни одно из настоящих решений не дает кортеж:
temp3 = tuple(set(temp1) - set(temp2))
альтернативно:
#edited using @Mark Byers idea. If you accept this one as answer, just accept his instead.
temp3 = tuple(x for x in temp1 if x not in set(temp2))
Как и другие неподдерживаемые ответы в этом направлении, он сохраняет порядок
3 ответа
- все назначения примитивных типов, за исключением длинного и двойного
- всех присвоений ссылок
- всех присвоений изменчивых переменных
- все операции java .concurrent.Atomic * classes
и, возможно, нечто большее. Посмотрите на jls .
Как отмечено в комментариях, атомарность не означает видимости. Таким образом, в то время как другой поток гарантированно не видит частично написанного int, он никогда не увидит новое значение.
Операции с длинными и двойными также находятся на общих 64-битных ЦПУ / g1], хотя нет никакой гарантии. См. Также этот запрос функции .
В Java чтение и запись 32-битных или меньших величин гарантированно будет атомарным. Под атомом мы подразумеваем, что каждое действие происходит за один шаг и не может быть прервано. Таким образом, когда у нас есть многопоточные приложения, операции чтения и записи являются потокобезопасными и их не нужно синхронизировать.
Например, следующий код является потокобезопасным:
public class ThreadSafe
{
private int x;
public void setX(int x)
{
this.x = x;
}
}
-
1..threadsafe в том смысле, что значение всегда будет точно либо исходным, либо установленным значением. Большинство актуальных значений по-прежнему обязательно не видны другим потокам из-за отсутствия "летучих" или "синхронизированный". – Mikko Wilkman 1 February 2011 в 09:00
-
2+1 к тому, что говорит @MikkoWilkman. Этот фрагмент кода не должен использоваться, поскольку он определенно не является потокобезопасным с точки зрения видимости памяти. – Knuckles the Echidna 18 May 2016 в 16:20
Было бы показаться , что назначения longs являются атомарными на основе этого метода в AtomicLong.java:
public final void set(long newValue) {
value = newValue;
}
Обратите внимание на отсутствие какой-либо синхронизации.
-
1
-
2То, что
valueявляетсяvolatile, не делает присвоениеvalueатомным, он просто избегает «публикации», вопросы. – Lyle Z 5 November 2013 в 17:56 -
3Он делает оба, см. JLS, раздел 17.7 : записи и чтения летучих длинных и двойных значений всегда являются атомарными. – maaartinus 5 November 2013 в 22:40
-
4
volatilelongs и doubles гарантированы как атомарные: java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7 – Joonas Pulakka 21 January 2011 в 09:2064 bit jvm, long and double assignments are also atomic.Ты уверен? Я бы сказал, что они предназначены для скомпилированного кода, но как насчет интерпретируемого кода? Наверное, ты прав, но есть ли какие-то гарантии? – maaartinus 21 January 2011 в 13:35