El próximo 3 de febrero, miércoles, tendrá lugar la siguiente charla del grupo de usuarios Artalde, esta vez hablando de algunas de las novedades de .NET Framework 4.0 para desarrolladores; una introducción a extensibilidad con MEF y paralelismo con TPL y PLINQ.

El lugar y hora, el de siempre; en la Universidad de Deusto, de 19:00 a 21:00 horas. El registro aquí.

En esta ocasión, será Luis Guerrero el que haga los honores y nos muestre las maravillas que nos trae la versión 4.0 del Framework…cremita de la buena!

Aquí os dejo la descripción completa de la charla:

En esta charlas veremos las novedades de las nos nuevas librerías que Microsoft incluye en .NET Framework para el desarrollo de extensibilidad de las aplicaciones, usado internamente por Microsoft para la extensibilidad de plug-ins en Visual Studio 2010, y cómo afrontar los problemas de concurrencia con Task Parallel Library.

MEF (Managed Extensibility Framework): El Framework de Extensibilidad para componentes administrados es una nueva librería incluida en el .NET Framework 4.0 que permite reutilizar aplicaciones y  componentes. Usando MEF, las aplicaciones .NET pueden avanzar de ser estáticamente compiladas a ser dinámicamente compuestas en runtime. Una aplicación MEF está compuesta de Parts que se exportan, se importan y se componen. http://www.codeplex.com/mef/

Parallel Programming in the .NET Framework: Son una serie de nuevas APIs que permiten al desarrollador trabajar con el software y paralelizar los componentes para sacar el máximo partido a toda la potencia que los procesadores de varios cores ofrecen. Veremos TPL (Task Parallel Library) que es la librería para trabajar con Task, que son las nuevas unidades mínimas de paralización (nunca más threads), también veremos PLINQ que nos ofrece que la posibilidad de ejecutar nuestras consultas de LINQ tradicionales en varios cores y con mínimo impacto en la modificación de nuestra query y para finalizar veremos las nuestras estructuras de datos para la programación paralela, como pilas, colas y listas.

Lugar:
Universidad de Deusto
Edificio ESIDE, Aula de videoconferencia (2º piso)
Avda Universidades, 24
48007, BILBAO

Dentro de la orientación a objetos nos encontramos dos tipos de métodos especiales, el constructor y el destructor. En .NET hay dos tipos de constructores de instancia (ctor) y de tipo (cctor) también llamado constructor estático.

Constructores

Cuando un tipo es accedido por primera vez, se ejecuta el constructor estático bajo un doble lock (Como implementar un Singleton concurrente) para asegurar que solamente se llama una vez, si además se está creando una instancia del objeto se llamará al constructor del objeto para inicializarlo. También se llama a todos los constructores base hasta que se llega a System.Object.

Hay que tener en cuenta que el constructor de un objeto no es más que un método que puede aceptar parámetros y que devuelve una referencia sí mismo a this. Como programadores no tenemos que manejar esta situación puesto que el propio compilador la realiza por nosotros.

Hay un caso excepcional en el que podemos crear un objeto pero no obtener una referencia a el nunca, si en el constructor se lanza una excepción. En este caso, el objeto se inicializa, se llama a los constructores base y se aborta el método en el punto en el que se lance la excepción, pero ya se ha reservado memoria para el objeto y nunca podremos acceder a esa referencia de ese objeto a medio construir.

public class Foo
{
    public DateTime DateTime { get; set; }
    public string file { get; set; }
    public Foo()
    {
        DateTime = DateTime.Now;
        string[] v = file.Split(',');
    }
}

Aquí tenemos un ejemplo de una clase que en el constructor lanzará una excepción de tipo NullReferenceException, realmente si se ha creado el objeto solo que si hacemos algo como:

Foo f = new Foo();

Nunca llegaremos a obtener la referencia del objeto hay creado y además tenemos que tener en cuenta que se tendrá que recolectar el objeto para liberar memoria en la siguiente recolección de basura.

Es por eso que hay que tener mucho cuidado con lo que se pone en el constructor porque podemos dejar a nuestro tipo inutilizado.

La situación se agrava si se lanza una excepción en el constructor de tipo, ya que no podremos acceder a ninguna variable estática ni crear instancias de este tipo.

Destructores o finalizadores

Los destructores (o finalizadores) son los métodos que se llamarán cuando el objeto ya no es usado y se reclama la memoria usada. En este caso es el CLR el que se encarga de llamar a este finalizador pues nosotros no tenemos ningún mecanismo para liberar un objeto.

Un finalizador se define de esta manera:

~Foo()
{
   Console.WriteLine("Adiossss !!");
}

Eso significa que cuando esa instancia del tipo Foo sea recolectada se ejecutará este método. Si miramos al IL generado por este programa realmente el destructor ha pasado a llamarse Finalize() y está marcado como virtual.

Además de definir un destructor de clase hay otro mecanismo para poder definir un destructor, implementando la interfaz IDisposable. Este es el único mecanismo que tiene un programador de .NET para poder definir un destructor de objeto y además poder llamarlo el mismo de codigo de usuario.

Para evitar que este método sea llamado otra vez por el CLR existe el método GC.SupressFinalize.

¿Cómo es llamado este método?

Cada vez que se realiza una recolección de basura el GC examina todos los objetos y si encuentra alguno que es finalizable, es decir, tiene destructor o implementa IDisposable, entonces ese objeto que está listo para ser recolectado pasa a la cola de finalización.

Cuando los objetos están en esa cola de finalización un Thread de alta prioridad se encarga de sacar un elemento de la cola, ejecutar su finalizador y marcarlo como listo para ser recolectado.

Consideraciones a tener en cuenta:

· Cuando el objeto está listo para ser finalizado se lleva a la cola de ReadyToFinalize y además todos los objeto de su grafo son marcados. Eso significa que si ese grafo de objeto normalmente moriría en esta recolección, ahora es promovida a la siguiente, simplemente porque su objeto raíz es finalizable.

· Las generaciones más viejas son recolectadas menos que las generaciones más jóvenes lo que indica que nuestro grafo de objetos puede permanecer vivo durante mucho tiempo hasta que es completamente finalizado y recolectado.

· Al utiliza un único thread, aunque está en prioridad alta, puede darse el caso de que el si tenemos una maquina con 32 procesadores y solamente tenemos una finalizado objetos la cola pueda crecer mucho.

· Hay que tener mucho cuidado con lo que se ejecuta en el finalizador porque si se produce una excepción el proceso entero se descarga. No estamos hablando de que se descargue el dominio de aplicación sino todo el proceso.

Garantías de finalización:

· Durante la ejecución normal de la aplicación y durante cada recolección de basura, se llamara a los finalizadores de los objetos que haya en la cola.

· Si el proceso termina sin la coordinación del CLR, llamando a TerminateProcess o ExitProcess, el CLR tendrá su primera noticia de que el proceso se está cerrando cuando se envíe el mensaje DLL_PROCESS_DETACH en el DllMain. Así que el CLR no tiene tiempo de hacer nada y lo único que puede pasar es que termine los finalizadores críticos (CriticalFinalizerObject).

· Si el proceso es cerrado con el pleno conocimiento del CLR, llamado a Exit o Enviroment.Exit, se finalizarán los objetos que están en la cola de finalización y los finalizadores críticos. Pero los posibles objetos que salgan de una recolección de basura listos para ser finalizados se quedarán sin ser finalizados.

· Si se descarga el dominio de aplicación entonces solamente se finalizarán los objetos que estuvieran en la cola de finalización y los finalizadores criticos.

El codigo del ejemplo: http://www.luisguerrero.net/downloads/ctor.zip

Saludos. Luis.

Durante la semana pasada estuve liado montando un servidor en mi casa, como podréis imaginaros le instale la última versión de Windows Server, Windows Server 2008 R2 que solamente está en 64bits.

Quería hacer dos cosas con el servidor, montar un Media Center Extender para mi Xbox360 y tener Hyper-V para mis maquinas virtuales. Al final he instado un Windows 7 32bits, virtualizado para HomeGroup, Media Center Extender y demás. La otra máquina virtual es otro Windows Server 2008 R2 con Visual Studio Team Foundation 2010 Beta 1 con Sql Server 2008.

Una vez que lo he tenido todo montado he estado curioseando entre los roles de Windows Server y me ha llamado la antecion el de Remote Desktop Services, ya que había leído mucho sobre el tema pero nunca lo había visto en funcionamiento.

La idea es básica, hacer que nuestro servidor de aplicaciones funcione como tal, pero a través de escritorio remoto, pero no como un escritorio remoto completo sino virtualizando solamente la ventana de la aplicación remota y enviándola al cliente.

Lo que me ha gustado es lo fácil que ha sido configurarlo en Windows Server 2008 R2 y la fantástica integración que tiene Windows 7.

Aquí podéis ver una captura del rol instalado en Windows Server 2008 R2, en la rama de RemoteApp Manager podéis pulsar en Add RemoteApp Programs.

Estos programas son solo programas instalados en el servidor, así que para mis cosas he instalado Office 2007 y Visual Studio 2010 que lo podéis ver en la lista.

Además disponemos de una aplicación web que nos permite lanzar las aplicaciones en nuestro ordenador simplemente haciendo un clic.

Y por último lo que podéis ver aquí es la integración de Windows7 con la lista de aplicaciones de servidor, en el que me dice que tengo 21 aplicaciones disponibles para usar, es básicamente un feed que la aplicación web que viene en Windows Server expone para que Windows 7 consuma.

Saludos. Luis.

Bajo este título se encuentra una de los clásicos problemas de concurrencia que seguramente más de uno se haya enfrentado en su vida de programador. En este artículo repasaremos las posibles implementaciones correctas e incorrectas de este patrón de manera concurrente.

Implementación sin concurrencia.

   1: public class Singleton<T> where T : new()

   2: {

   3:     private static T instance = new T();

   4:     public static T Instance

   5:     {

   6:         get

   7:         {

   8:             return instance;

   9:         }

  10:     }

  11: }

  12: public class SingletonV2<T> where T : new()

  13: {

  14:     private static T instance;

  15:     public static T Instance

  16:     {

  17:         get

  18:         {

  19:             if (instance == null)

  20:             {

  21:                 instance = new T();

  22:             }

  23:             return instance;

  24:         }

  25:     }

  26: }

  27: public class CacheManager

  28: {

  29:     private static CacheManager instance = new CacheManager();

  30:     public static CacheManager Instance

  31:     {

  32:         get

  33:         {

  34:             return instance;

  35:         }

  36:     }

  37:     private CacheManager()

  38:     {

  39:  

  40:     }

  41: }

Como se puede ver esta es la implementación para una clase cualquiera y de una manera genérica, en la que el único requisito que pedimos es que sea una referencia y se pueda construir una instancia.

El problema de estas dos implementaciones es que cuando se construye el tipo se inicializa el valor del Singleton, lo que puede resultar en una degradación del rendimiento y solamente se desea implementar cuando se vaya a acceder al valor de la instancia. Para solucionar ese problema se puede implementar un Singleton perezoso que solamente cuando se accede la primera vez se inicializa.

   1: public class CacheManagerV2

   2: {

   3:     private static CacheManagerV2 instance;

   4:     public static CacheManagerV2 Instance

   5:     {

   6:         get

   7:         {

   8:             if (instance == null)

   9:             {

  10:                 instance = new CacheManagerV2();

  11:             }

  12:             return instance;

  13:         }

  14:     }

  15:     private CacheManagerV2()

  16:     {

  17:  

  18:     }

  19: }

Pero llegado a este punto nos encontramos con un problema muy importante, que pasa si dos Threads a la vez intenta acceder al valor de la instancia de cualquiera de nuestros Singletones, el resultado puede ser catastrófico, porque se puede iniciar más de una instancia de la clase o cada uno de los Threas se puede llevar una referencia distinta del singleton haciendo que trabajen con instancias diferentes.

¿Cómo se puede solucionar este problema?

Hay varias maneras de solucionarlo, la primera de todas sería usar un bloqueo para sincronizar el acceso a este recurso. Vamos a ver una serie de ejemplos y porque estos ejemplos están bien o mal implementados.

Utilizando bloqueos

   1: public class BadCacheManager

   2: {

   3:   private static BadCacheManager instance;

   4:   private static object syncRoot = new object();

   5:   public static BadCacheManager Instance

   6:   {

   7:       get

   8:       {

   9:           S0

  10:           if (instance == null)

  11:           {

  12:               S1

  13:               lock (syncRoot)

  14:               {

  15:                   instance = new BadCacheManager();

  16:               }

  17:           }

  18:           return instance;

  19:       }

  20:   }

  21:   private BadCacheManager()

  22:   {

  23:  

  24:   }

  25: }

BadCacheManager: Mal

Esta implementacion no funcionaría porque puede darse la casualizad de que durante la primera comprobación (S0) y justo antes de que se instancie la clase (S1) puede haber una instrucción y puede darse la casualidad de que se interrumpa el thread (t0) justo en ese instante, lo que otro thread (t1) evaluaria S0 (true, es nulo) adquiriría el bloqueo pero esperaría (t1) porque el otro thread (t0) lo tiene asignado, así que t0 se despertaría crearia el objeto, después t1 haría lo mismo dando como resultado dos instancias. Además de todo esto no se sincroniza el almacenamiento de la variable instance con un memory barrier (fence) marcando la variable como volatile o usando Thread.MemoryBarrier().

   1: public class DoubleLockVolatileCacheManager

   2: {

   3:     private static volatile DoubleLockVolatileCacheManager instance;

   4:     private static object syncRoot = new object();

   5:     public static DoubleLockVolatileCacheManager Instance

   6:     {

   7:         get

   8:         {

   9:             if (instance == null)

  10:             {

  11:                 lock (syncRoot)

  12:                 {

  13:                     if (instance == null)

  14:                     {

  15:                         instance = new DoubleLockVolatileCacheManager();

  16:                     }

  17:                 }

  18:             }

  19:             return instance;

  20:         }

  21:     }

  22:     private DoubleLockVolatileCacheManager()

  23:     {

  24:  

  25:     }

  26: }

DoubleLockVolatileCacheManager: Bien *

Esta implementación esta bien pero a medias, en la implementacion de .NET el CLR se asegura que independientemente del tipo de reordenacion del procesador, del modelo de memoria y de la atomicidad de las lecturas y escrituras siempre funciona, de hecho es lo que .net utiliza internamente para asegurarse que el constructor estatico (cctor) de un tipo solamente se ejecute una vez. Pero el modelo de memoria de .NET permite reordenaciones de lectura/escritura de variables no volatiles, así que habría que haber marcado la instancia como volatie o insertar un Thread.MemoryBarrier, aquí tenemos la implementacion correcta.

   1: public class DoubleLockCacheManager

   2: {

   3:    private static DoubleLockCacheManager instance;

   4:    private static object syncRoot = new object();

   5:    public static DoubleLockCacheManager Instance

   6:    {

   7:        get

   8:        {

   9:            if (instance == null)

  10:            {

  11:                lock (syncRoot)

  12:                {

  13:                    if (instance == null)

  14:                    {

  15:                        DoubleLockCacheManager tmp = new DoubleLockCacheManager();

  16:                        Thread.MemoryBarrier();

  17:                        instance = tmp;

  18:                    }

  19:                }

  20:            }

  21:            return instance;

  22:        }

  23:    }

  24:    private DoubleLockCacheManager()

  25:    {

  26:  

  27:    }

  28: }

   1: public class BadLazy<T>

   2: {

   3:   private T internalValue;

   4:   private bool isInitialized;

   5:   private object syncRoot = new object();

   6:   private Func<T> factory;

   7:  

   8:  

   9:   public BadLazy(Func<T> factory)

  10:   {

  11:       this.factory = factory;

  12:   }

  13:  

  14:   public T Value

  15:   {

  16:       get

  17:       {

  18:           lock (syncRoot)

  19:           {

  20:               if (!isInitialized)

  21:               {

  22:                   internalValue = factory();

  23:                   isInitialized = true;

  24:               }

  25:           }

  26:           return internalValue;

  27:       }

  28:   }

  29: }

Todos los ejemplos que hemos utilizado aquí utilizan lock (aka Monitor.Enter) para implementar un sistema de bloqueo en los recursos compartidos del Singleton, pero lo ideal para casi todos los casos es no utilizar bloqueos.

¿Cómo se puede implementar un algoritmo libre de bloqueos?, la respuesta está en la granularidad de la concurrencia, gruesa o fina. Nosotros queremos granularidad fina para hacer que los Threads estén el menos tiempo en un bloqueo haciendo así que todo el sistema responda mucho mejor. Una granularidad fina es mucho más complicada de implementar pero tiene un mejor rendimiento y respuesta del sistema porque hay menos contención.

Ahora vamos a ver como sería el Singleton perezoso sin bloqueos.

   1: public class Lazy<T> where T : class, new()

   2: {

   3:    private T value;

   4:    public T Value

   5:    {

   6:        get

   7:        {

   8:            if (value == null)

   9:            {

  10:                Interlocked.CompareExchange(ref value, new T(), null);

  11:            }

  12:            return value;

  13:        }

  14:    }

  15: }

Como se puede observar se ha simplificado mucho el código y ahora lo único que tenemos es un Interlocked.CompareExchange, en el que se compara el valor de primer argumento con el del último argumento y si son iguales entonces se establece en el primer argumento el valor de segundo parámetro, así que si nuestra instancia es nula entonces se crea la instancia y se establece. Lo interesante de esta forma de implementarlo es que no tenemos que preocuparnos por el modelo de memoria de .net por la reordenación de instrucciones ni por nada, ya que el Interlocked.CompareExchange es atómica a nivel de hardware, es decir nuestro procesador nos asegura que sea instrucción CMPXCHG es atómica.

Como se puede observar la granularidad de este algoritmo es muy fina porque solamente se bloquea en el momento justo de establecer la variable.

Un ejemplo de una granularidad fina en el uso de los bloqueos la podemos observar en la implementación de este diccionario concurrente.

   1: public class ConcurrentDictionary<TKey, TValue> : IDictionary<TKey, TValue>, ICollection<KeyValuePair<TKey, TValue>>, IEnumerable<KeyValuePair<TKey, TValue>>

   2: {

   3:     private ReaderWriterLock rw = new ReaderWriterLock();

   4:     private Dictionary<TKey, TValue> dic = new Dictionary<TKey, TValue>();

   5:     private int timeout = -1;

   6:     public void Add(TKey key, TValue value)

   7:     {

   8:         rw.AcquireWriterLock(timeout);

   9:         try

  10:         {

  11:             if (!dic.ContainsKey(key))

  12:             {

  13:                 dic.Add(key, value);

  14:             }

  15:         }

  16:         finally

  17:         {

  18:             rw.ReleaseWriterLock();

  19:         }

  20:     }

  21:  

  22:     public bool ContainsKey(TKey key)

  23:     {

  24:         bool res = false;

  25:         rw.AcquireReaderLock(timeout);

  26:         try

  27:         {

  28:             res = dic.ContainsKey(key);

  29:         }

  30:         finally

  31:         {

  32:             rw.ReleaseReaderLock();

  33:         }

  34:         return res;

  35:     }

  36:  

  37:     public ICollection<TKey> Keys

  38:     {

  39:         get

  40:         {

  41:             ICollection<TKey> res = null;

  42:             rw.AcquireReaderLock(timeout);

  43:             try

  44:             {

  45:                 Dictionary<TKey, TValue> tmp = new Dictionary<TKey, TValue>(dic);

  46:                 res = tmp.Keys;

  47:             }

  48:             finally

  49:             {

  50:                 rw.ReleaseReaderLock();

  51:             }

  52:             return res;

  53:         }

  54:     }

  55:  

  56:     public bool Remove(TKey key)

  57:     {

  58:         bool res = false;

  59:         rw.AcquireWriterLock(timeout);

  60:         try

  61:         {

  62:             res = dic.Remove(key);

  63:         }

  64:         finally

  65:         {

  66:             rw.ReleaseWriterLock();

  67:         }

  68:         return res;

  69:     }

  70:  

  71:     public bool TryGetValue(TKey key, out TValue value)

  72:     {

  73:         bool res = false;

  74:         rw.AcquireWriterLock(timeout);

  75:         try

  76:         {

  77:             res = dic.TryGetValue(key, out value);

  78:         }

  79:         finally

  80:         {

  81:             rw.ReleaseWriterLock();

  82:         }

  83:         return res;

  84:     }

  85:  

  86:     public ICollection<TValue> Values

  87:     {

  88:         get

  89:         {

  90:             ICollection<TValue> res = null;

  91:             rw.AcquireReaderLock(timeout);

  92:             try

  93:             {

  94:                 Dictionary<TKey, TValue> tmp = new Dictionary<TKey, TValue>(dic);

  95:                 res = tmp.Values;

  96:             }

  97:             finally

  98:             {

  99:                 rw.ReleaseReaderLock();

 100:             }

 101:             return res;

 102:         }

 103:     }

 104:  

 105:     public TValue this[TKey key]

 106:     {

 107:         get

 108:         {

 109:             TValue res = default(TValue);

 110:             rw.AcquireReaderLock(timeout);

 111:             try

 112:             {

 113:                 if (dic.ContainsKey(key))

 114:                 {

 115:                     res = dic[key];

 116:                 }

 117:             }

 118:             finally

 119:             {

 120:                 rw.ReleaseWriterLock();

 121:             }

 122:             return res;

 123:         }

 124:         set

 125:         {

 126:             if (ContainsKey(key))

 127:             {

 128:                 rw.AcquireWriterLock(timeout);

 129:                 try

 130:                 {

 131:                     dic[key] = value;

 132:                 }

 133:                 finally

 134:                 {

 135:                     rw.ReleaseWriterLock();

 136:                 }

 137:             }

 138:         }

 139:     }

 140:  

 141:  

 142:  

 143:     public void Add(KeyValuePair<TKey, TValue> item)

 144:     {

 145:         Add(item.Key, item.Value);

 146:     }

 147:  

 148:     public void Clear()

 149:     {

 150:         rw.AcquireWriterLock(timeout);

 151:         try

 152:         {

 153:             dic.Clear();

 154:         }

 155:         finally

 156:         {

 157:             rw.ReleaseWriterLock();

 158:         }

 159:     }

 160:  

 161:     public bool Contains(KeyValuePair<TKey, TValue> item)

 162:     {

 163:         return ContainsKey(item.Key);

 164:     }

 165:  

 166:     public void CopyTo(KeyValuePair<TKey, TValue>[] array, int arrayIndex)

 167:     {

 168:         throw new NotImplementedException();

 169:     }

 170:  

 171:     public int Count

 172:     {

 173:         get

 174:         {

 175:             int count = -1;

 176:             rw.AcquireReaderLock(timeout);

 177:             try

 178:             {

 179:                 count = dic.Count;

 180:             }

 181:             finally

 182:             {

 183:                 rw.ReleaseReaderLock();

 184:             }

 185:             return count;

 186:         }

 187:     }

 188:  

 189:     public bool IsReadOnly

 190:     {

 191:         get { return false; }

 192:     }

 193:  

 194:     public bool Remove(KeyValuePair<TKey, TValue> item)

 195:     {

 196:         bool res = false;

 197:         if (ContainsKey(item.Key))

 198:         {

 199:             Remove(item.Key);

 200:         }

 201:         return res;

 202:     }

 203:  

 204:  

 205:  

 206:     public IEnumerator<KeyValuePair<TKey, TValue>> GetEnumerator()

 207:     {

 208:         IEnumerator<KeyValuePair<TKey, TValue>> res = null;

 209:         rw.AcquireReaderLock(timeout);

 210:         try

 211:         {

 212:             Dictionary<TKey, TValue> tmp = new Dictionary<TKey, TValue>(dic);

 213:             res = tmp.GetEnumerator();

 214:         }

 215:         finally

 216:         {

 217:             rw.ReleaseReaderLock();

 218:         }

 219:         return res;

 220:     }

 221:  

 222:  

 223:  

 224:     IEnumerator IEnumerable.GetEnumerator()

 225:     {

 226:         return null;

 227:     }

 228:  

 229:  

 230:  

 231:     IEnumerator<KeyValuePair<TKey, TValue>> IEnumerable<KeyValuePair<TKey, TValue>>.GetEnumerator()

 232:     {

 233:         return null;

 234:     }

 235:  

 236:  

 237: }

En el que únicamente cuando se realizan operaciones en el diccionario se intenta bloquear lo menos posible además de que no se utiliza lock (aka Monitor.Enter) sino ReaderWriterLock que permite tener varios lectores y un solo escritor concurrentemente. Se podría haber utilizado ReaderWriterLockSlim que mejora sensiblemente el rendimiento pero esta implementación era para .NET 2.0 y ReaderWriterLockSlim solo funciona con .NET 3.5 además de que en Windows Vista se ha mejorado la implantación nativa.

Os podeis descargar el codigo de ejemplo de aquí

http://www.luisguerrero.net/downloads/Singleton.zip

Espero que os sirva de ayuda.

Saludos. Luis.

Hola a todos, el 18 y 19 de Febrero en Portugal se celebra el DevDay09 de Microsoft en la cual voy a dar con mi compañero Ricardo una charla sobre desarrollo de aplicaciones en Microsoft Surface, así que si estáis por la zona nos veremos allí.

Saludos. Luis.

WUX203 - Desenvolvimento Aplicações para Microsoft Surface

Datos:

Instituto Superior Técnico

Campus do TagusPark

Porto Salvo

Pues eso, nos han regalado un proyecto en mi casa, y con la terraza que hay en mi casa que íbamos ha hacer?, pues jugar el RockBand y al Guitar Hero, aquí os dejo algunas fotos del evento, :p

Para los que no lo sepáis, vivo en Madrid y ahora con el frio que hace ha sido curioso jugar así. Espero encontrar algo parecido en Londres!!

Saludos. Luis.

No suelo escribir sobre las novedades que la web nos ofrece a menos que sea algo interesante para el programador, pero viendo esto de google chrome no he podido evitarlo. Creo que todo el mundo se ha bajado el navegador en cuestión si no lo ha hecho lo invito.

La primera impresión buena, es un diseño sencillo. Empiezo a navegar y me llevo una sorpresa. Normalmente siempre tengo abierto el process explorer un sustituto del administrador de tareas de windows, y cuando he mirado al árbol de procesos me he llevado una sorpresa muy grande.

Resulta que el navegador de chrome abre un proceso por cada pestaña, parece que eso de aislar cada tab por si uno falla que falle solo esa pestaña lo han llevado al extremo.

Pero resulta que esto es una muy mala práctica. Como sabréis una de la cosa más costosa para Windows es iniciar un proceso, ya que debido a las características de seguridad y aislamiento Windows genera una memoria virtual para cada proceso además de todas las estructuras necesarias para que el proceso se pueda iniciar. Pues me parece que esta solución de los “ingenieros” de software de google, es la más obvia, cutre y sobre todo la más fácil. Ni que decir tiene que este modelo de navegador hace que se generen muchos procesos, que, por muy ligeros que sean, tienen que cargar sus dll, reservar memoria a Windows y demás tareas. Es como si en la programación de páginas web cambiásemos el modelo de hosting de asp.net a un modelo cgi en que cada vez que se hace una petición se inicia el w3_wp.exe. Eso por ejemplo lo vemos una barbaridad, pues la gente de google es lo que ha hecho.

No sé si sabéis que en .net existe el mismo problema para los entornos de hosting, un proceso, asp.net o Sql Server. Imaginaros por un momento que tengo mi web en asp.net en un hosting compartido, y una de las web que se aloja en ese servidor, que también está dentro del mismo proceso w3_wp.exe hace una operación no valida y genera una excepción crítica, resulta que el proceso se cerraría y se reiniciaría y yo que también estoy hay sufriría la incompetencia de mi vecino de memoria. Esto desde luego es una cosa muy fuerte, por eso en .NET existe el concepto de Dominio de Aplicación, System.AppDomain, que básicamente es un aislamiento lógico para las aplicaciones, incluso si están dentro del mismo dominio. Esto no es gratuito puesto que a poco que conozcas un poco la plataforma Windows, sabrás que Windows comparte las dll cargas en el mismo proceso, lo que hace que se mejore el consumo de memoria.

Que por cierto si dentro del mismo tab cambias la web el proceso que has usado para renderizar la anterior se cierra y se abre uno nuevo, toda una aberración, ni siquiera reutilizan el proceso, como yo decía un modelo cgi de renderizado de webs. También para los plugins utiliza el mismo proceso, podemos verlo con las líneas de comando.

Así que lo único que digo sobre el navegador de google, que me importa muy poco, por no decir nada que soporte acid test o lo que sea o los estándares, es que el modelo de aislamiento de tab me parece una castaña muy gorda y que en vez de agitar internet con un lanzamiento de estas características para presentar esta cosa, por favor cállate y presenta algo innovador de verdad.

Actualización: Parece que Microsoft en la beta del IE8 con el UAC activado hace lo mismo, y tengo que decir que me parece una castaña muy gorda, parchear el navegado y no inventar nada nuevo. Yo no tengo el UAC activado.

Windows Vista con UAC gentileza de mi colega Pedro Laguna

Y este es mi escritorio sin UAC con IE8 Beta2 con varios tabs y el process explorer abierto.