Now imagine hashing resources into points on the circle. They could be URLs, GUIDs, integer IDs, or any arbitrary sequence of bytes. Just run them through MD5 or SHA and shave off everything but 8 bytes (and if anyone tells you that you shouldn’t use MD5 for this because it isn’t secure, just nod and back away slowly. You have identified someone not worth arguing with). […]

La otra cara de esta moneda la han tenido lenguajes y paradigmas que cambiaban la manera de programación hacia esquemas que hicieran más fácil escalar en el número de hilos/cores a la vez que permitían una programación más natural de programas multihilo. Estos nuevos paradigmas también evitaban, por diseño, los problemas que se dan con los candados, reentrancia, etc.

El paradigma sobre el que hablaré hoy es el de los actores. Este mecanismo, que data de 1986, se utiliza en Erlang y en Scala, por ejemplo, pero no he encontrado ejemplos de cómo implementar este mecanismo en C++, salvo un artículo de 1993 de Kafura, Mukherji y Lavender en el que no se hace uso de ninguna característica «moderna» de C++, como los tipos parametrizados o la sobrecarga de operadores.

En resumen, el mecanismo de actores se basa en definir un actor como un objeto reactivo que se ejecuta en su propio hilo. Son similares a los objetos stricto sensu, en el sentido de que se les puede enviar invocaciones (en mi caso eventos), y los actores responden ejecutándolos, como los objetos normales. No obstante, son diferentes porque las invocaciones se ejecutan de manera que no causan problemas de concurrencia. ¿Cómo? Pues asegurando que todas las invocaciones sobre un actor se ejecutan en un mismo hilo. En este sentido, un actor también aglutina, en general, un hilo de ejecución propio en el que se ejecutan las llamadas al mismo (esto puede no ser así exactamente, pero la idea es la misma).

Existe una diferencia con los paradigmas tradicionales de programación. Por ejemplo, para no causar problemas de concurrencia, todos los métodos de un objeto se podrían marcar como «synchronized» al estilo de Java. Esto, efectivamente, hace que no haya problemas de concurrencia (al menos los más usuales), ya que todas las invocaciones a un objeto se realizan en exclusión mutua. Sin embargo, una invocación a objeto normal lleva consigo asociada un hilo de ejecución, y el hilo de ejecución del objeto llamante es el que realiza la llamada al objeto llamado, con lo que también se tienen que prevenir problemas como interbloqueos, esperas de candados, etc.

En resumen, sería casi como un sistema basado en eventos en donde los objetos se envían mensajes que son a su vez procesados en los hilos respectivos de cada actor. Ahora bien, ¿cómo implementar en C++ este mecanismo sin ser excesivamente intrusivo, teniendo en cuenta que el mecanismo de envío de eventos no existe en C++? Pensé en utilizar boost.signal, pero éste no asegura que el objeto receptor va a ejecutar la señal en su propio hilo. Los requisitos que establecí pues para el desarrollo fueron los siguientes:

1. El mecanismo debe ser poco intrusivo, en el sentido de que las clases que quieran beneficiarse de este mecanismo no tienen por qué escribirse heredando de un interfaz en particular, sino que sólo tienen que definir una serie de tipos para saber tratarlas como actor.
2. Cualquier clase puede definir de manera sencilla qué eventos puede recibir y cómo actuará ante cualquier evento, y estos serán los únicos requisitos que tendrá que especificar la clase.
3. Las clases pueden modificar de forma sencilla qué eventos producen y reciben.
4. Las clases no tendrán que preocuparse de tratar con hilos, asincronía, almacenamiento y reproducción de eventos, etc.
5. El mecanismo de envío de eventos debe estar integrado en el lenguaje C++ de forma natural. Por ejemplo, con un operador que muestre que se está enviando un evento: objeto < < mensaje;.

Con estos requisitos, pensé hacer la clase actor que pudiera aceptar como parámetro cualquier otra clase, y convertirla así en un actor. Este mecanismo es poco intrusivo, sólo obligando a que la clase que se quiere beneficiar de este mecanismo especifique qué eventos es capaz de recibir. La clase actor que me quedó fue la siguiente, con comentarios al estilo de la literate programming (si alguien está interesado le puedo pasar el código sin los comentarios):

template <typename Klass>
struct actor
{
    typedef typename Klass::events_type VariantType;

Uno de los requisitos que tiene que proveer la clase que se va a convertir en actor es ofrecer el tipo VariantType con los distintos eventos que va a poder recibir. Para esto se usará el tipo boost.variant como se verá después.

    typedef actor<Klass> self;

    actor (Klass& a)
        : delegate_ (a)
    {
        thread_ = boost::thread (boost::ref (*this));
    }

Cada actor posee su propio hilo. Esto, por supuesto puede modificarse después. Sólo quería hacer una prueba de concepto. En scala existen schedulers que enlazan actores con hilos.

    // Thread func.
    void operator()()
    {
        std::cout << “running thread” << std::endl;

        while(!stop_)
        {
            bool b;
            {
                boost::lock_guard<boost::mutex> guard (list_mutex_);
                b = el_.empty();
            }

            if (b)
            {
                boost::unique_lock<boost::mutex> lock (mut_);

                // wait on the cond. var.
                cond_.wait (lock);
            }

            while (true)
            {
                VariantType vtv;
                {
                    boost::lock_guard<boost::mutex> guard (list_mutex_);
                    if (el_.empty())
                        break;

                    vtv = el_.front();
                    el_.pop_front();
                }

                // Call the delegate without holding the mutex locked
                boost::apply_visitor (detail::event_caller<Klass> (delegate_),
                                      vtv);
            }
        }
    }

El operator()() de la clase actor ejecuta el código del hilo. He utilizado variables de condición porque me parecen más ricas semánticamente. El hilo básicamente extrae eventos de la cola de eventos y los ejecuta sobre el delegate. Como los eventos de la cola pueden ser de diferentes tipos (nótese que este punto es especialmente difícil en C++), hay que utilizar estructuras que permitan tratar diferentes tipos de eventos de forma genérica. Para eso he usado la construcción boost::apply_visitor de boost.variant. Con el uso de una clase especial, detail::event_caller, que se verá más abajo, se consigue llamar a la clase original, a los métodos process(Evento), para cada uno de los eventos recibidos.

    template <typename Event>
    self& operator<<(Event& e)
    {
        std::cout << “Received event” << std::endl;
        {
            boost::lock_guard<boost::mutex> lock (list_mutex_);
            el_.push_back (e);
        }

        // signal that a new event is available
        cond_.notify_one();

        return *this;
    }

El operador << se puede usar para enviar un evento al actor. Esta es una construcción que queda muy natural. Enviar un mensaje es diferente a realizar una llamada, aunque también se puede pensar en un mecanismo de llamada a función modificado. Al final, el envío de mensajes, como se verá después, será algo así como actor << Clase::Evento(valores);.

    void join()
    {
        thread_.join();
    }

    void stop()
    {
        stop_ = true;
        cond_.notify_one();
    }

private:
    Klass& delegate_;

    typedef std::deque<VariantType>  event_list;
    event_list el_;
    bool stop_; // stop?
    boost::thread thread_;

    boost::mutex mut_;
    boost::mutex list_mutex_;
    boost::condition_variable cond_;
};

Por completitud, aquí está la clase detail::event_caller. Es necesaria para visitar un tipo boost.variant a través de la función boost::apply_visitor. Simplemente llama a la función process() correspondiente.

namespace detail
{

template <typename Klass>
struct event_caller : public boost::static_visitor<>
{
    Klass& instance_;

    event_caller (Klass& i)
        : instance_ (i)
    {
    }

    template <typename T>
    void operator()( T const & operand ) const
    {
        instance_.process (operand);
    }
};
}

Llegamos a la clase sobre la que queremos construir el actor, llamada para este ejemplo TestClass. La clase define internamente un par de eventos (Event1 y Event2), y, como comentamos arriba, el tipo events_type, como un boost.variant de los diferentes eventos que puede recibir. Se pueden ver los métodos process() más abajo. En este caso la clase tiene métodos propios para retornar un actor interno. Esto no tiene por qué ser así, y como se ha visto, los actores son independientes de las clases de las que actúan en representación.

class TestClass
{
public:
    typedef actor<TestClass> actor_type;

    struct Event1
    {
        int data;
    };

    struct Event2
    {
        std::string ss;
    };

    // Obligatory
    typedef boost::variant< Event1, Event2 > events_type;

    actor_type& the_actor()
    {
        return *actor_;
    }

    // Ctor.
    TestClass()
        : actor_ (new actor_type (*this))
    {
    }

    ~TestClass()
    {
        actor_->stop();
        actor_->join();
        delete actor_;
    }

private:
    actor_type* actor_;

public:
    void process (Event1 const& e)
    {
        std::cout << “Processed event: “  << e.data << std::endl;
    }

    void process (Event2 const& e)
    {
        std::cout << “Processed event 2: “  << e.ss << std::endl;
    }
};

Por último, ¿cómo se usa este mecanismo de actores? Lo ideal es proveer de mecanismos que sean semánticamente ricos y que sigan el principio de mínima sorpresa. Con las clases de arriba podemos escribir código sencillo como el siguiente:

    TestClass::Event1 ev;
    ev.data = -2;

    TestClass::Event2 ev2;
    ev2.ss = “abcdef.”;

    TestClass tc;

    TestClass::actor_type& ac = tc.the_actor();

Primero se crean un par de eventos de los dos tipos que puede recibir la clase TestClass, y se obtiene el actor ac. Se puede usar ese actor para enviar eventos a la clase:

    // Send the event2
    ac << ev2;

    // Send message
    ac << ev;
    for (int i = 0; i < 2000; ++i)
    {
        ev.data = i;
        ac << ev;
        ac << ev2;
    }

Aquí se envía primero un evento de tipo Event1, y luego otro del tipo 2. Después se entra en un bucle que envía ambos mensajes, modificando el primer evento con un dato distinto. El programa va mostrando la salida de eventos de la clase en orden:

...
Processed event: 1996
Processed event 2: abcdef.
Processed event: 1997
Processed event 2: abcdef.
Processed event: 1998
Processed event 2: abcdef.
Processed event: 1999
Processed event 2: abcdef.

Un último apunte. Las diferencias con los actores de otros lenguajes dinámicos (Scala, por ejemplo), son que en estos lenguajes se puede especificar un procesado basado en máquinas de estados, como por ejemplo, cuando se recibe el evento 1, después sólo se puede recibir el evento 2. Esta máquina de estados se puede implementar. Es una primera implementación de prueba.

No dudéis en contactar conmigo para ideas o comentarios.

• SIGMA 30mm 1.4 EX DC HSM for NIKON, un objetivo grandioso para formato DX, que fue el objetivo preferido cuando usaba la D200.
• Nikon Zoom-Nikkor 55-200 AFS DX f/4-5.6G ED, un zoom sin pretensiones, pero que no está nada mal, y además pesa muy poco. Lo he usado poco, pero es ideal si quieres tener un zoom largo y no quieres cargar con un objetivo tocho.
• SIGMA 17-70 f. 2.8-4.5 DC SLD Macro, un zoom muy versátil desde gran angular (17mm) hasta telefoto medio (70mm) y con una gran apertura (f/2.8) y con características de macro.

Tampoco sabía que se habían lanzado en masa a mostrar cómo resolver este problema en otros lenguajes, pero enlazo aquí la resolución en Clojure también porque esa página lleva enlaces a otros ejemplos de cómo resolverlo, y enlaces a los foros de Arc.

having a baby leaves you this way

(a.k.a. wonders of iso 3200)

I saw her in the bathroom and I had to do this

Nikon D700 + Nikkor 50mm/1.4.

Y su MySpace.

PD. ¿Por qué todos los artistas emergentes tienen que tener su sitio en MySpace? Es lo más caótico y peor diseñado que me podía haber imaginado en mis peores pesadillas. Supongo que los veinteañeros lo verán de lo más normal tener páginas totalmente desestructuradas, pero yo…

¡Aquí está! ¡Qué bonita es! Con un día de vida en el hospital. No he tenido tiempo ni de subir más fotos, pero todo se andará

Here she is! How beautiful she is! Just one day after birth at the hospital. I haven’t had time to upload any more photos, but hopefuly I will in the near future

D700 + 50mm/1.4 AF

El vídeo no tiene desperdicio. De hecho, comienza tal que así (las negritas son mías):

Los medios de comunicación de izquierdas han atizado en las últimas semanas al papa…

Para que luego digan que lo de las dos españas está muy trasnochado… Pero eso es con mucho lo de menos. Del vídeo, periodismo + derechos humanos ha destacado un conjunto de frases. Las negritas, de nuevo, son mías.

“En aquellos países donde se difunde la fe católica, la enfermedad del SIDA se expande menos que en las regiones donde se reparte el profiláctico”

“Hay que tener cuidado y no rasgar el producto con las manos; en fin, la manicura en África no destaca”

“Y si a esto sumamos que los ciudadanos del Tercer Mundo no saben leer, el uso del preservativo puede ser un peligro”

“Prácticamente toda la población del continente se encuentra en zonas donde el clima es eminentemente caluroso, lo que hace dificil la conservación de los preservativos”

“Aun si entendieran lo que leen, es dudoso que los africanos lleguen a aplicar directrices como la de tener cuidado al desplegar la funda. Muchos habitantes de zonas rurales del continente negro tienen unas manos que pueden ser no aptas para la manipulación del preservativo”.

Eso sí que es rigor periodístico. Y respeto por los demás. El problema son los preservativos, por supuesto, no que la población sea analfabeta. Hay que luchar, por supuesto, para que siga siendo así y no puedan ni leer la documentación adjunta. Y si no saben nada de nada y se creen a pies juntillas lo que le dice la Iglesia, pues mejor que mejor…

Me quedo sin palabras. Sobre todo porque los religiosos que están al pie del cañón en misiones allí en «el continente negro», están a favor del preservativo.

Como dicen por ahí, sin embargo, quizá sea incluso más penoso que haya gente que se lo crea.

She’s comming but not here yet Just to be prepared, we bought a d700 to get just great photos of her

This is her room, that we prepared with such care and eagerness. I just have to fix that bulb and it will be done. Note the nice frame made by my mother with her name. Lovely.

Nikon D700 + Stone Age Tamron 17mm/3.5.