Multithread

No existe una respuesta de forma general a tu pregunta, las aplicaciones multithread dependen fuertemente de que las librerías de clases que empleas sean reentrantes (y esto depende de que se usen o no variables globales en dichas librerías) para permitir el cambio de contexto a otro thread mientras se está ejecutando código de una clase. Para hacer lo que dices, debes asegurarte primero que la biblioteca de clases que empleas sea compatible con threads, y solo entonces, emplearla... Cuando una biblioteca de clases reúne estas características, suele estar documentado en dicha librería, tanto el modo de hacerlo, como las limitaciones que se tienen al hacerlo.
Espero haberte sido de ayuda (aunque solo sea parcialmente)

La aplicación es muy simple. La idea es tener una clase multithread que ejecutara una serie de operaciones. Cuando le llegue el evento oportuno se crea un objeto y realiza unos cálculos simples. No hay variables globales ni ninguna complicación. No se utilizan las mfc's. Hay alguna clase por defecto en visual c++, de la que pueda derivar la mía directamente, ¿cómo es en java derivando de tthread?

Por muy simple que sea la aplicación... si el conjunto de clases que empleas no es reentrante... tu aplicación se la pegará probablemente, si la haces multithread y las clases que empleas no están preparadas para un cambio de contexto. No puedo responder de modo general. No se trata de las clases que tú crees, sino de las que usas en tu aplicación.

Para finalizar, existe algún manual, ¿libro o tutorial que explique la multitarea en internet?. Cuando dices clase usadas no creadas, a que clases te refieres, ¿si son de Visual C++?. Gracias y perdona mi insistencia, pero es que es una aplicación para un banco y es muy critica.

Cuando digo clases no creadas por ti, me refiero a aquellas clases donde no dispones de información sobre si soportan varios threads o no. La reentrancia es una propiedad (podríamos decir matemática) de un trozo de código (en este caso, el código que implementa los métodos de una clase) que permite saber si dicho código se puede ejecutar en paralelo consigo mismo. Si dos procesos (threads) entran en el mismo trozo de código, y el código es reentrante, no hay problema, pero si no lo es... puedes tener corrupción de datos, al no controlar que se hace con los mismos... (uno de los threads puede estar tocando datos a mitad de una modificación del otro thread y dejarlos al final en un estado incoherente) la idea está asociada normalmente a los datos empleados por las rutinas... si ambas instancias del mismo código en ejecución manipulan los mismos datos (datos globales a la aplicación) en general, el código no será reentrante, ya que podría comenzar a ejecutarse el código de uno de los procesos y modificarse los datos, mientras el otro proceso no ha terminado aún de tocarlos.
Te pongo un caso concreto: imagina la rutina del sistema printf() es una rutina que `aparentemente' no manipula datos globales, porque no tienes constancia de ello. Sin embargo, existen implementaciones reentrantes y no reentrantes de la misma rutina. Si usas threads con un printf() no reentrante, tienes que asegurarte (con semáforos se puede hacer) que nunca habrá dos printf() en ejecución al mismo tiempo, ya que de lo contrario, se podrían corromper los datos internos usados por printf() y que tres horas más tarde... en una llamada a printf() tu programa se cuelgue, sin saber por que.