Barrapunto

Digamos que el hilo A esta pintando cosas en pantalla mientras el hilo B hace cosas de red, ambos pueden funcionar sin problemas. Gran parte del trabajo no va colisionar, y para las partes que si pueden colisionar, se usan sistemas que garanticen que no (semaforos, por ejemplo). Asi cuando B tiene que actualizar la lista de datos a mostrar porque los a recibido de la red, pide que se lo garanticen y solucionado. Y por cierto, la pila no se comparte. Por cado hilo hay que guardar cierta información no compartida ademas de la pila, como en que punto de ejecucion se encuentra, el valor de los registros, prioridades que tiene, gestores de excepcion, etc. Algunos definen multihilo como un multiproceso en el que cierto procesos comparten por defecto mucho incluido el código a ejectuar. Por eso otros prefieren hacer multiproceso y usar memoria compartida, para que cuando hay que operar sobre esa memoria, quede bien claro (o visto de otra forma, compartir lo justo, con lo que se esta más atento a esos casos).

A ver, multihilo y multiproceso son conceptos distintos.

A grosso modo se puede decir que un proceso es gestionado por el sistema operativo mientras que un hilo es gestionado por la propia aplicación. El SO da tiempo de CPU a los distintos procesos que tiene en ejecución, y cada uno de estos procesos puede tener,a su vez, varios hilos en marcha.

Cada uno de ellos tiene sus ventajas y sus inconvenientes: un proceso necesita mucho tiempo para ser cambiado por otro en la CPU porque tiene que guardar el estado del procesador (y mas elementos) en la pila y restaurar el estado para el nuevo proceso; un hilo se ahorra todo esto porque está en el mismo proceso, con lo que el cambio de uno a otro es mas rápido.

Una aplicación multihilo no tiene porque tener una unica pila. Puede tener tantas como necesite, igual que puede tener varias secciones de datos. Todo depende de la organización del proceso en memoria.

El tema es muy extenso y lo tengo algo olvidado, pero por aqui va el tema.

Multihilo y multiproceso viene a ser lo mismo, dos hilos de ejecución independientes (con su pila y sus registros). La diferencia es que en multihilo se comparten las páginas de código y por defecto la sección de datos es compartida.

Siempre que haya concurrencia se puede sacar partido del paralelismo. Hasta hace poco en linux todo eran procesos y los hilos (el cambio de contexto entre hilos) se gestionaban a nivel de biblioteca (los pthreads). Ahora en linux todo son hilos y punto. Como ves, después de todo es lo mismo.

Existen varios tipos de multihilo, según el soporte que ofrezca el sistema operativo para ellos y como lo aproveche un sistema de hilos concreto para ese sistema operativo. Puede ser que el sistema operativo ni siquiera sepa si un proceso tiene varios hilos o no, puede que vea a cada hilo como si fuera un proceso completo (aunque tenga algunas propiedades especiales, como compartir la memoria con otro proceso), puede que tenga completo conocimiento de la situación y el planificador asigne cpu a hilos concretos. Y en este caso no es ningún problema asignarle una cpu a un hilo del proceso y otra cpu al otro.
Pero en cualquier caso, cada hilo tiene su propia pila, si no la cosa no funcionaría. Propia en el sentido de tener su propio puntero de pila, aunque la memoria que esté usando sea accesible por los otros hilos del mismo proceso.