2011-11-04 7 views
8
public static int rank(int key, int[] a) { 
     int lo = 0; 
     int hi = a.length - 1; 
     while (lo <= hi) { 
      // Key is in a[lo..hi] or not present. 
      int mid = lo + (hi - lo)/2; 
      if  (key < a[mid]) hi = mid - 1; 
      else if (key > a[mid]) lo = mid + 1; 
      else return mid; 
     } 
     return -1; 
    } 

El método estático anterior realiza la búsqueda binaria. ¿Es seguro para subprocesos? Sé que las variables locales son seguras para hilos, pero "a" aquí es una matriz, lo que significa que es un objeto en Java, ¿verdad? ¿Es eso un problema? La matriz solo se está leyendo, no se ha modificado de ninguna manera, por lo que supongo que este método es seguro para subprocesos. Pero quiero asegurarme de entender por qué.¿Son seguras las matrices de Java en un método estático?

Gracias!

Respuesta

7

No hay matrices no son generalmente threadsafe. Si su código es en este caso depende de si otros subprocesos tienen acceso al arreglo que pasó. Debido a que los arreglos se pasan por referencia, otros subprocesos pueden tener acceso a ellos.

Si solo crea/modifica la matriz en una sola secuencia, o si transfiere una copia que se copia de forma segura para hilos, estará bien.

+0

Ya veo. Entonces, el código no es seguro para subprocesos aunque la matriz no se modifique, ¿verdad? Pero mientras que cada hilo que llama a este método lo haga con un objeto de matriz diferente, la vida es buena. – user247866

+4

BTW - No creo que sea correcto decir que las matrices se pasan por referencia (pero entiendo lo que quiso decir). Más precisamente para decir que la referencia de matriz se pasa por valor. ¡Gracias! – user247866

+1

Solo porque algún otro subproceso podría modificarlo al mismo tiempo que lo está leyendo. –

0

sí, es seguro para subprocesos, como usted dice que usted lee solamente la matriz, el único problema posible puede ser si un otro hilo es la actualización de la matriz al mismo tiempo que este método lo lee

+4

Otro hilo aún puede editar un elemento de la matriz en el mismo momento. – BalusC

+0

sí, eso es lo que quise decir también –

+1

Eso inicialmente no estaba en su respuesta, lo editó justo después dentro del período de gracia de 5 minutos. – BalusC

1

El método en sí es seguro para subprocesos, ya que solo toma sus argumentos y los lee, sin publicarlos en ningún otro subproceso. Pero eso no significa que no puedas tener un problema de enhebrado. Todo depende de dónde provienen los argumentos.

Si los argumentos constituyen estado compartido entre subprocesos, entonces cada acceso a este estado se debe sincronizar de alguna manera. Pero debe establecer una política de sincronización entre hilos para proteger el acceso a este estado. Por lo tanto, este método, o el que llama de este método, debe asegurarse de que el acceso al estado sea seguro para subprocesos. Sin saber de dónde provienen los argumentos, es imposible saber si este código es seguro para subprocesos o no.

Cuestiones relacionadas