Creo que su empresa no debería usar subprocesos múltiples.
Después de hacer un proyecto de multiproceso masivo, encontré que dos técnicas eran fundamentales para hacer que las cosas funcionaran. Primero , el código tenía que estar escrito correctamente. Cada campo debía verificarse manualmente para asegurarse de que se había declarado correctamente y de que estaba correctamente sincronizado dondequiera que se hiciera referencia. (Advertencia: estoy simplificando un poco las cosas aquí para que mi respuesta sea breve, o, en cualquier caso, más breve.) En segundo lugar , el código se tuvo que probar ejecutándolo de forma sencilla en y máquinas multinúcleo: muchos minutos utilizando el 100% de cada núcleo. (Y si solo usa el 2% de cada núcleo, como lo hizo a menudo para mí, también es un error).
Es posible que pueda administrar esto, pero su organización no puede. Incluso si entendieron el problema, y no lo saben, no tienen la experiencia.
La mayoría de los idiomas proporcionan formas de evitar esto. Si tiene un lector de zócalo, que generalmente tiene su propio hilo, pídale que lleve la información al hilo principal de la manera más rápida y sencilla posible. Mejor aún, busque las clases / funciones del sistema que manejarán la parte del hilo de la lectura por usted. Use una cola que ejecute "eventos" uno tras otro, como hacen la mayoría de las API de GUI. (Para el caso, use la cola de eventos de la API de la GUI). Si necesita un procesamiento paralelo, probablemente pueda encontrar algún tipo de "subproceso de trabajo" que le permita mantener los datos / campos en un solo subproceso, manejando todas las transferencias por usted.
Enfatice todos los peligros del multihilo. (Historias de miedo: mi error favorito involucró un par de líneas como: int i = 5; i = i * i; , lo que resultó en que i tuviera un valor de 35. Uno que vi mucho fue: if (thing != null) thing.reset(); lanzando una excepción de puntero nulo). la única esperanza es hacer que comprendan que están entrando en un mundo nuevo, nuevo y extraño, y que tal vez deberían dar un gran paso atrás.
No estoy muy seguro de cómo se debe manejar el subprocesamiento múltiple . Si el trabajo puede ser entregado a una sola persona, y todo lo que hacen se tira si fracasa, está bien. Pero un equipo solo será tan fuerte como su miembro más débil, e incluso un buen programador tendrá problemas con el multiproceso en toda regla. Espero que la gente del idioma encuentre la manera de hacerlo seguro. He visto algún software útil por ahí Pero creo que es mejor evitar los subprocesos múltiples a menos que el tiempo de ejecución sea crítico y un buen programador o un equipo probado esté disponible.