Re: miembros estáticos y multithreading
Hola a todos.
Yo voy a poner mi granito de arena... o más bien mi granito para atascar
los engranajes...
Los problemas de sincronización denotan un grave defecto de diseño... en
el hardware y el sistema operativo (ya imaginaba a alguno levantando el
látigo, je je). Por supuesto todo esto no deja de ser una elucubración mía
que posiblemente carezca de sentido, pero es como lo veo.
¿Por qué tenemos que preocuparnos nosotros de la sincronización, que está
en la tripas del sistema operativo? Hace unos años era entendible:
limitaciones técnicas, rendimiento, etc... ¿Pero hoy en día? La
informática está atascada, el hardware más, comienzan a proliferar los
procesadores multinúcleo y el sistema operativo y el hard de alrededor es
idéntico. ¿No sería mucho más rentable en cuanto a rendimiento que fuera
la propia electrónica la que hiciera directamente la sincronización? ¿Qué
ocurre si lanzamos un bloqueo desde el pipeline de dos cores? Hala, toda
la previsión de ejecución, el adelanto de ciclos, todo perdido...
De todos modos creo que los AS/400 de IBM implementas directamente
sincronización (Si no son esos, seguro que existe un SO/Hard que lo hace
automáticamente, he oído hablar de él pero no recuerdo el nombre)...
No me refiero a que toda la memoria esté sincronizada, sino tener una
nueva palabra reservada, por ejemplo "sync".
sync list<MiRegistro>mi_lista_de_registros.
Ante cada operación de lectura/escritura la entrada/salida de la sección
crítica o el semáforo o el mutex debería hacerse automáticamente.
O mejor aún, que fuera completamente transparente. Sería el compilador el
que mirara si el programa tiene hilos e introduciría la sincronización
automáticamente en aquellas que estuvieran compartidas. Y si fuera el
sistema operativo, mejor que mejor...
¿Qué les parece?
On Thu, 02 Apr 2009 08:23:43 +0200, Daniel Gutson
<danielgutson@...>
wrote:
> Hola Enrique,
>
> las condiciones de carrera estan asociadas a la modificacion del dato,
> es
> decir, de ver quién llega primero a escribir el dato.
> Si tenés 50 giles leyendo, no pasa nada, no hay nadie compitiendo por el
> recurso.
>
> Acordáte que un mutex es Mutually Exclusive; no hay nada de excluyente
> entre
> dos tipos que quieren leer lo mismo, es compatible.
>
> Daniel.
>
> pd: el static const sólo aplica a integrales, no a flotantes.
>
> 2009/4/1 Enrique Nieloud <enieloud@...>
>
>>
>> Hola Dani,
>>
>> Gracias por la data,
>>
>> > Por qué podría ser un problema, siendo un dato read only? No veo
>> condición
>> > de carrera.
>> Ok, es bueno saberlo. Es decir que si es readonly no habría problema
>> entonces. No estaba seguro.
>> ¿Lo mismo puede decirse si tengo varios lectores simultáneos sobre un
>> cacho de memoria pedida x malloc?
>>
>> > Además la diferencia entre enum y static const int en este caso es
>> sólo a
>> > nivel compilación, no tiene ninguna implicancia en la generación de
>> código
>> Ok. Yo venía sistemáticamente evitando declaraciones de miembros
>> estáticos por no saber bien lo que discutimos sobre multi-threading en
>> el párrafo anterior. Usaba unos horribles #defines. Pensando en como
>> evitarlos me pareció que una forma era usar el enum hack. Ahora ya
>> está uso "static const var".
>>
>> > (a menos obviamente que operes con la dirección del static const).
>> si, si, desde ya.
>>
>> nuevamente gracias!
>>
>> >
>>
>
> >
--
--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y desarrollo
========================================
Si no hay café para todos, no habrá para nadie.
-- Ernesto 'Che' Guevara.
RSS Feed