30 junio 2008

Multihilos en xHarbour - Parte III

En la anterior entrega, vimos los problemas que ocurren cuando se incrementan o decrementan variables desde 2 o más hilos y no se protegen con un mutex.

Si ejecutan el último ejemplo de la entrega anterior, pero sin ejecutar la función ThreadSleep(10), casi con seguridad tendrán el siguiente error interno: Premature Pointer Release detected
El error ocurre mucho más frecuentemente con procesadores multicore porque verdaderamente están ejecutando el código en paralelo.

¿A qué se debe? Se debe justamente a que los contadores de referencia del puntero que mantiene al Mutex, se desincronizan porque no se actualizan correctamente, tal como se vió en el primer ejemplo de la última entrega.

¿Cómo solucionar este problema? Desde el 28/6/08 el CVS de xHarbour tiene la corrección aplicada y también en la distribución xHarbour 1.0 de PuertoSur tiene el problema corregido en todos los casos.

24 junio 2008

xHarbour 1.0 de PuertoSUR

Muchos lo han pedido y ya está disponible la distribución de xHarbour de PuertoSUR de la versión 1.0.
En estos momentos están disponibles para bajar las siguientes compilaciones:

xHarbour 1.0 compatible con FWH 2.4 para Borland 5.5
xHarbour 1.0 compatible con FWH 2.5/2.6 para Borland 5.5
xHarbour 1.0 compatible con FWH 2.7 y sup para Borland 5.5

Esta distribución como anteriores, se provee en forma de instalador que busca la ubicación del compilador de Borland, lo configura y configura los archivos para compilar y enlazar aplicaciones simples.

La distribución incluye junto con las librerías de xHarbour, algunas librerías de contribuciones y algunas librerías extras, además de algunos arreglos posteriores a la liberación:

rddads.lib compatible con Advantage 8.x
mysql3.lib compatible con MySql 3.x
mysql5.lib compatible con MySql 5.x
hbcomm.lib librería de comunicaciones serie con funciones compatibles en parámetros y funcionalidad a las de FW, para paliar la falta de esta funcionalidad en algunas versiones de FWH.

22 junio 2008

Multihilos en xHarbour - Parte II

El acceso a recursos compartidos

En la entrega anterior vimos como poner en marcha un hilo paralelo de ejecución, dando lugar a la ejecución multihilo.

En esta oportunidad, veremos una de las problemáticas más comunes de la programación multihilo. El acceso a recursos compartidos.

¿Qué es un recurso? Cualquier cosa que se pueda leer, escribir y/o ejecutar. Una variable, un archivo, un alias, una función, un socket, etc.

Cualquier programador de xBase que haya hecho programas multiusuario sabe que para poder modificar un registro, primero debe bloquearlo.
Supongo que la mayoría sabe por qué hay que bloquearlo y no me refiero "a que si no da error de registro no bloqueado".
La razón de bloquear el registro es para que dos o más usuarios no puedan modificar el mismo registro al mismo tiempo.

Esta protección a nivel de recursos en general se realiza usando la entidad Mutex.

HB_MutexCreate() es la función que permite crear una entidad Mutex.
El Valtype() de una variable que contiene un Mutex es P, o sea, un puntero.

Un Mutex sirve para varias cosas, pero en esta entrega veremos el uso más común, que es como semáforo.

HB_MutexLock() es la función que marca el Mutex como bloqueado por el thread que llamó a la función.
Esta función retorna solamente cuando obtuvo el bloqueo del Mutex.

Mientras un hilo bloquee un Mutex y cualquier otro hilo que intente bloquear el mismo Mutex, quedará bloqueado y en estado de espera a que se desbloquee el Mutex.
Cuando el Mutex esté disponible, sólo uno de los hilos obtendrá acceso al Mutex, mientras que los demás seguirán esperando.

HB_MutexUnlock() es la función que desbloquea el Mutex y lo deja disponible para que otro hilo lo pueda bloquear.

Además de estas dos funciones, que son las más usadas, existen otras.

HB_MutextryLock() es la función intenta bloquear el Mutex y si lo logra, retorna .T. o un .F. en caso contrario.

HB_MutexTimeOutLock() es la función que intenta bloquear el Mutex durante un tiempo que se indica como segundo parámetro. Retorna .T. si logra el bloqueo y .F. en caso contrario.

El ejemplo más trivial para usar un Mutex es como protección en la actualización de un contador. Más de uno se preguntará por qué hay que bloquear si solamente queremos incrementar?
El tema es que el proceso de incrementar requiere de 3 pasos. Leer, incrementar, grabar. Entonces, podría suceder que dos procesos leyeran simultaneamente y luego al grabar, el contador solamente se habría incrementado una vez en lugar de 2 veces.

Veamos un ejemplo que podamos probar para ver más claramente el asunto:


Static lFinalizar := .f.
Static nGlobalCounter := 0
Static aResult[2]

Function Main()
cls
StartThread(@mostrar())
StartThread(@enparalelo(),1)
StartThread(@enparalelo(),2)
DevOut("Presione una tecla para finalizar o espere 5 segundos",,1,0)
inkey(5)
lFinalizar := .t.
WaitForThreads()
cls
@2,0 say "Thread 1 - LocalCounter="+str(aResult[1])
@3,0 say "Thread 2 - LocalCounter="+str(aResult[2])
@4,0 say "Total "+str(aResult[1]+aResult[2])
@6,0 say " GlobalCounter="+str(nGlobalCounter)
@8,0 say "Diferencia "+str(aResult[1]+aResult[2]-nGlobalCounter)


Procedure enparalelo( nId )
Local nLocalCounter := 0
Local nLinea := GetThreadId()
do while !lFinalizar
  nLocalCounter++
  nGlobalCounter++
  ThreadSleep(10)
enddo
aResult[nId] := nLocalCounter
Return

Procedure mostrar()
Local nStatus := 1, cStatus := "|/-\"
Local nLinea := GetThreadId()
do while !lFinalizar
  DevOut(nGlobalCounter,,nLinea,10)
  ThreadSleep(500)
enddo
Return


La diferencia debería ser 0 (cero), pero no siempre es así. Esto muestra por qué es necesario proteger la variable al modificar su valor.
El código correcto es:


Static lFinalizar := .f.
Static nGlobalCounter := 0
Static aResult[2]

Function Main()
Local mtxCounter
cls

mtxCounter := HB_MutexCreate()

StartThread(@mostrar(),mtxCounter)
StartThread(@enparalelo(),1,mtxCounter)
StartThread(@enparalelo(),2,mtxCounter)
DevOut("Presione una tecla para finalizar o espere 5 segundos",,1,0)
inkey(5)
lFinalizar := .t.
WaitForThreads()
cls
@2,0 say "Thread 1 - LocalCounter="+str(aResult[1])
@3,0 say "Thread 2 - LocalCounter="+str(aResult[2])
@4,0 say "Total "+str(aResult[1]+aResult[2])
@6,0 say " GlobalCounter="+str(nGlobalCounter)
@8,0 say "Diferencia "+str(aResult[1]+aResult[2]-nGlobalCounter)


Procedure enparalelo( nId, mtxCounter )
Local nLocalCounter := 0
Local nLinea := GetThreadId()
do while !lFinalizar
  nLocalCounter++
  HB_MutexLock(mtxCounter)
  nGlobalCounter++
  HB_MutexUnlock(mtxCounter)
  ThreadSleep(10)
enddo
aResult[nId] := nLocalCounter
Return

Procedure mostrar(mtxCounter)
Local nStatus := 1, cStatus := "|/-\"
Local nLinea := GetThreadId()
do while !lFinalizar
  DevOut(nGlobalCounter,,nLinea,10)
  ThreadSleep(500)
enddo
Return


Un ejemplo más complejo es el de una clase que implemente una pila o cola. Es totalmente necesario que mientras un hilo intenta agregar o quitar un elemento, otro hilo no pueda ni agregar ni quitar elementos. Por lo tanto la actualización del array que mantiene la pila o cola, debe estar protegido por un mutex.

En la próxima entrega, más usos de la entidad Mutex.

11 junio 2008

Multihilos en xHarbour - como compilar

Como compilar los ejemplos:

Los ejemplos que encontrarán en estas notas son sencillos y se podrán compilar con el archivo \xharbour\tests\bldtest.bat de la siguiente forma:

c:\xharbour\tests> bldtest.bat /mt test1.prg

Por default el archivo .bat está preparado para usar el compilador de Borland.
Para usar otro compilador será necesario establecer algunas variables de entorno.

También pueden crear un archivo xcomp.bat con las siguientes lineas y que permite compilar con el compilador de Borland.


//------------------------------------------------
@harbour %1 /n %2 %3 %4 %5 %6 %7 %8 %9
@bcc32 -tWM -I\xharbour\include -L\xharbour\lib -5 -O2 -d %1.c debug.lib vmmt.lib rtlmt.lib gtwin.lib lang.lib rddmt.lib macromt.lib ppmt.lib dbfntxmt.lib common.lib codepage.lib pcrepos.lib sixcdxmt.lib dbffptmt.lib hbsixmt.lib

//------------------------------------------------


Hay que tener en cuenta que las líneas del archivo son solamente 2, las que comienzan con el caracter @.

Luego de construir el archivo .bat, podrán compilar de la siguiente forma:

x:\xharbour\tests> xcomp test1

02 junio 2008

Multihilos en xHarbour - Parte I

Como toda cosa nueva, como todo cambio, siempre cuesta y siempre genera incertidumbre.
Crear programas multihilos es un cambio respecto de la programación habitual, pero la verdad, es que la teoria de los multihilos es muy simple.

Usar multihilos es tan simple de usar como el SQL.
El SQL tiene 7 comandos.
Para usar multihilos es suficiente con conocer cerca de 10 instrucciones.

¿Tan simple es?
Bueno, la respuesta es un poco más compleja que un Si o un No.

Si nos guiamos por la cantidad de instrucciones/funciones a usar, y por la sencilla explicación de lo que hace cada una de ellas, contestaría que Si.

Pero. ¿Es posible medir la simplicidad de la programación por la cantidad de instrucciones que posee?

Yo, como muchos, creo que la programación es un arte como lo es la pintura. Ahora, si es tan simple combinar colores, ¿por qué yo no soy un pintor? ¿Por qué no pagarían ni 10 centavos por una "obra" mía?

Nuestra diseñadora gráfica me contestaría que no es suficiente con saber combinar. También hay que saber cómo combinar los colores (y tener buen gusto, algo que no es mi fuerte).

Ahh, así que no es suficiente con conocer 5, 7 o 10 instrucciones, también es necesario saber cómo y cuándo usarlas y cada una de sus opciones.

Al igual que los corredores profesionales de autos, no solo saben manejar muy bien, también conocen de mecánica y de aerodinámica, y además, horas y horas de prácticas para conocer los límites del auto.

Un programador debe conocer las instrucciones, cuándo aplicarlas y cómo combinarlas, pero en la alta competencia no es suficiente.
Además debe conocer pormenores del motor de ejecución y pormenores del sistema operativo.
Eso se aplica tanto al SQL como a los multihilos.

Quizás esta introducción no es muy amigable, pero es la realidad. La teoría es sencilla, pero la práctica algunas veces se complica, pero con práctica y buenas normas de programación para multihilos, se podrá salir adelante.

Pero mejor, vayamos a los multihilos que es el tema.

Primera ejecución de una función en paralelo

La ejecución de una rutina en paralelo con otra es muy sencilla. Sólo es suficiente con poner StartThread( @enparalelo() ) para que la función enparalelo() comience a ejecutarse.

//-----------------------------------------------
Static lFinalizar := .f.

Function Main()
cls
StartThread(@enparalelo())
DevOut("Presione una tecla para finalizar",,1,0)
inkey(0)

Procedure enparalelo()
Local nStatus := 1, cStatus := "|/-\"
Local nLinea := GetThreadId()
do while !lFinalizar
  DevOut(cStatus[nStatus],,nLinea,10)
  if ++nStatus > 3
    nStatus := 1
  endif
  ThreadSleep(500)
enddo
Return
//-----------------------------------------------


De la misma forma, si ejecutamos 2 veces StartThread(), estaremos haciendo que se ejecuten 2 hilos.


Function Main()
cls
StartThread(@enparalelo())
StartThread(@enparalelo())
DevOut("Presione una tecla para finalizar",,1,0)
inkey(0)


Es posible pasar parámetros al thread? Si.

StartThread(@enparalelo(),xParam1,xParam2,...)


Resumiendo, estas son las opciones de ejecución para lanzar threads.

// usando puntero a la funcion (puede ser publica o estatica)
StartThread(@funcion(),)

// usando el nombre de la funcion (debe ser publica)
StartThread("funcion",)

// usando el nombre del metodo
StartThread(objeto,"metodo",)

// usando el puntero al metodo
StartThread(objeto,__ObjPtr(objeto,"metodo"),)

// usando un codeblock
StartThread(codeblock,)

Antes de finalizar esta primera entrega, voy a dar una lista de las funciones que se usan en multihilos y de las cuales veremos sus usos, comportamientos, casos de uso y advertencias de uso.

HB_MutexCreate
HB_MutexLock
HB_MutexUnlock
HB_MutexTryLock
HB_MutexTimeOutLock

Subscribe
SubscribeNow
Notify
NotifyAll

StopThread
JoinThread
KillThread
WaitForAllThreads
GetThreadId

Hasta la próxima

13 abril 2008

Monopolio o No-Monopolio, esa es la cuestión

Comencé a pensar en este artículo hace un tiempo, pero ahora tengo la necesidad de terminar de escribirlo.

El movimiento del software libre ya tiene unos cuantos años y una gran cantidad de adeptos y simpatizantes.

Software libre vs Software propietario, es la cuestión?
Hoy muchos artículos en revistas y blogs discuten acerca de dos supuestas posiciones antagónicas. Sofware libre vs Software propietario.
Los partidarios del software libre enarbolan fuertemente la bandera de la libertad, incluso a costa de coartar algunas libertades.
Por otra parte los creadores de software propietario defienden sus creaciones y sus empresas y detrás de ellas su esfuerzo (pocas veces las grandes empresas se meten en estas discusiones).

Pero, llegan a alguna conclusión válida estas discusiones? o son peleas filosóficas?
Yo creo que son discusiones sin sentido, simplemente porque ambos bandos tienen una parte de la verdad y porque ambos pueden convivir.
Entonces, quién se beneficia? Los beneficiados son unos pocos y quizás hasta les interese estas discusiones, porque hace quitar la atención de la verdadera discusión.

La verdadera discusión debería ser: hasta cuando los gobiernos permitirán y alimentarán los monopolios?
Hasta cuando nosotros mismos alimentaremos y permitiremos los monopolios?

Sabemos que los monopolios son malos, pero como estamos siendo afectados?

Cómo nos afectan los monopolios ?
Los monopolios afectan todo lo que los rodea y cuando se trata de algo muy metido en la sociedad, afecta a toda la sociedad.
Hoy en día Microsoft está afectando a toda la sociedad, y si no se lo controla, Google podría llegar a hacer algo similar con internet, lo cual podría ser peor ya que internet es multiplataforma.

Un monopolio es como un virus y muy comparable con el virus del HIV.
Lo primero que afecta un monopolio es la competencia y busca por todos los medios combatir cualquier intento de surgimiento de una competencia.

Inicialmente no afecta a los consumidores y hasta parece bueno o tonto.
(los CD de Windows no tienen protección anticopia y hasta se consiguen los generadores de claves para instalar el producto)

Un monopolio, puede no poner precios altos y hasta regalar productos, pero el fin es simplemente matar la competencia (Netscape vs Explorer)

Cuando tiene a los consumidores totalmente dependientes y sin amenazas que combatir, comienza el proceso de ahogamiento de los mismos consumidores tal como una boa constrictora lo hace con su presa.

El proceso de ahogamiento de un monopolio
El proceso comienza con los canales de venta y los contratos abusivos que limitan la instalación de programas en computadoras nuevas.
O los contratos con otras empresas para impedir el desarrollo de productos.
(que pasó con Kylix y Corel Linux).

Paralelamente comienza a verse el principio de tratar al usuario de inepto, incluido al administrador del sistema.
Claro, crearon un producto que hasta un dummy podría usar y ahora creen que todos son unos dummys a los que hay que decirles que pueden y que no pueden hacer con el sistema.
(Ej: Esta carpeta contiene archivos que mantienen el sistema en correcto funcionamiento.
No debería modificar su contenido)

El siguiente nivel de estrangulamiento es dictaminar como deben crear sus productos las compañías de hardware para permitirles el soporte en la siguiente versión del sistema operativo. Incluyendo cláusulas de no publicación de cierta información técnica del producto y de no publicación de drivers para soporte de un sistema operativo vigente.
( Cómo puede ser que existan:
  • Notebooks con sistemas de disco no estándares sin drivers para Windows XP.
  • Placas de video de última generación con características que sólo pueden usarse bajo Windows Vista y si se quiere utilizar con otro sistema operativo, esas características no estarán disponibles. Un nuevo modelo de drivers hace necesario tener un driver para cada modelo de tarjeta lo cual aumenta el costo de desarrollo y testeo, y eso lo pagan tanto los usuarios de Windows Vista como los usuarios de otros sistemas operativos.
    Las nuevas características sólo se podrán usar bajo Windows Vista y siempre y cuando éste se los permita.
    Y para coartar aún más las libertades del usuario, al momento de utilizar ciertas características avanzadas, algunos dispositivos podrán ser desactivados bajo criterio y decisión del sistema operativo.
    No era mejor que el hardware se comunicara con el hardware y el proceso de autorización y autenticación fuera independiente del sistema operativo? No claro, porque esto abriría la competencia.
)

A estas alturas tenemos:
  • usuarios dependientes de sus computadoras pero que no pueden utilizar muchas de sus características.
  • Tenemos usuarios que compran notebooks nuevas con el logo de Windows Vista Capable sin embargo no son capaces de mostrar nada mejor que un Windows XP y funcionar peor que con un Windows XP y sin posibilidad de instalar Windows XP bajo la amenaza de perder la garantía !!!!
Como puede existir una cláusula de esta naturaleza? Como puede el fabricante del hardware decirme que tal programa no puedo instalarlo en esa computadora?
Alguien compraría un auto con la cláusula "Si bien este auto posee 4 asientos, el cargar más de 2 personas invalida la garantía sobre el motor".

Los afectados
En algunas notebooks modernas, no impiden que instale Linux, impiden que instale Windows XP al no proveer los drivers. (Al momento de escribir estas líneas Windows XP es un producto vigente y con soporte de la misma forma que Windows Vsita)
Y quién otra que la misma Microsoft puede estar interesada en que no puedas usar Windows XP?
Y quién es el único afectado? el usuario.

Otros afectados son los desarrolladores.
Microsoft en su sed de abarcar todo, intenta establecer que el único lenguaje válido para hacer programas para Windows Vista y posteriores sea algún lenguaje podado-recortado-adaptado para funcionar bajo la plataforma .NET

Y como los viejos desarrolladores son un poco reacios, hay que apuntar a los futuros desarrolladores.
Pero para que estos futuros desarrolladores no usen más que .NET, se instalan nuevos centros de cómputos con servers y máquinas de última generación en cada facultad en donde se enseñe programación, para que se use .NET, con profesores adeptos a .NET y nada de profesores que enseñen a pensar, solo profesores que enseñen .NET.
Pero TAN es malo .NET? no, .NET no es malo en si mismo, es mala la práctica monopólica de intentar imponer .NET como único sistema para utilizar las características de un sistema operativo.
Y esto sólo es posible gracias al monopolio.

Y esto no termina acá...
Y como si todo esto fuera poco y para seguir mostrando otra vuelta más de la boa constrictora.
En estos días, contra todo pronóstico coherente y con abrumadoras y nauseabundas prácticas de
corrupción y monopolio, Microsoft logró aprobar un estandar ISO para intercambio de documentos cuando ya existe un estandar ISO para esa función.
ATENCION: Los siguientes link pueden contener detalles de prácticas monopólicas no apto para cardíacos.
http://barrapunto.com/article.pl?sid=08/04/02/1047257
http://www.openxml.info/index.php?option=com_content&task=view&id=27&Itemid=7

Moraleja
Las empresas están para ganar plata, pero cuando la forma de ganar plata se realiza por prácticas anticompetitivas los gobiernos y/o la justicia deberían poner coto a esas prácticas.
Cuando esto no ocurre, los afectados somos nosotros mismos.

04 marzo 2008

Advantage Database Server 9

Texto de un mail recibido desde Abox:

SYBASE iANYWHERE Anuncia

ADVANTAGE DATABASE SERVER 9


Advantage lanza al mercado su nueva versión 9. Esta marcará el final del ciclo de vida de las versiones antiguas de Advantage data Server. A partir del 30 de marzo de 2008, las versiones 5,6, y 7.x no se les dará soporte técnico. Para continuar con el apoyo los usuarios de la versión 7.x de Advantage pueden comprar las actualizaciones de las versiones más recientes (versiones admitidas, Advantage 8 o 9.)

Por un período de transición de 6 meses después del lanzamiento de Advantage 9, los clientes pueden comprar nuevas licencias de Advantage 9 y también puede recibir un duplicado de Advantage 8 para ser utilizados de conformidad con los términos del acuerdo a la licencia de software. Este período de transición se ha diseñado para permitir que los usuarios actuales puedan integrar plenamente la versión 9 sin interrumpir los ciclos de liberación los cuales se hubieran planeado previamente. Después de este período de transición, los clientes todavía pueden comprar las versiones antiguas de Advantage, pero no tendrán derecho a nuevas versiones sin la compra de la actualización adecuada. Actualizaciones de estas licencias se pueden comprar en cualquier momento y en los precios vigentes.

Que hay de nuevo en la versión 9 de Advantage
  • Mejoras en el soporte de FoxPro: Advantage 9 soportara la versión de Visual FoxPro 9.
  • 64-bit en servidores Windows y Linux Advantage Database Server ha sido adaptado para funcionar como aplicación nativa de 64-bit en la versiones de x64 de Windows y Linux.
  • SQL Debugger: Un SQL debugger ha sido añadido a la versión 9 de Advantage Data Architect, Permitiendo a los desarrolladores depurar scripts SQL, procedimientos almacenados, disparadores, y funciones definidas por el usuario..
  • Notificaciones de Eventos : las notificaciones de eventos es un mecanismo que permite al servidor notificar proactivamente a los clientes de que un evento que les interesa se ha producido.
  • New Default User Groups: admin, public, debug, backup
  • TDataSet Descendant Version Switching Utility
  • Dynamic Server Configuration
  • Optimized Replication Functionality and Enhancements


Para ver información mas detallada de las novedades de la versión 9, pueden ir a la zona de desarrolladores de Advantage.

Download

La versión de Advantage 9 esta disponible para descarga.