שכיח למדי (אבל לא בכל מקום) - ולא תמיד באותה רמת מורכבות
 
ריבוי חוטים מהווה דרך חשובה לנצל את ריבוי הליבות וריבוי המעבדים במחשבים שונים.
 
אפליקציה שמעוניינת להשתמש ביותר ממעבד אחד על המחשב שעליו היא רצה - צריכה להשתמש בריבוי חוטים או בריבוי תהליכים.
 
מאחר והנטיה כיום להגברת ביצועי החומרה היא הוספה של ליבות, ולא העלאת תדר (זה נכון בתחום השרתים והדסקטופים, זה הגיע גם לסמארטפונים - זה קיים בצורה מצומצמת בהרבה במערכות משובצות מחשב - למרות ששם לפעמים יש ריבוי מעבדים לא-סימטריים) - השימוש בכלים של ריבוי חוטים ו/או תהליכים - גדל, וסביר שימשיך לגדול.
 
בין ריבוי חוטים לריבוי תהליכים - לריבוי חוטים יש תקורה נמוכה יותר מבחינת צריכת זכרון ומבחינת ביצוע context switch (לא צריך להחליף את כל מיפוי הזכרון הוירטואלי במעבר בין חוטים שונים) - בהרבה מקרים ריבוי חוטים מועדף על פני ריבוי תהליכים (המקום שבו לריבוי תהליכים יש יתרון משמעותי הוא במערכות scale-out - שאמורות להיות מסוגלות לרוץ על מספר שרתים הולך וגדל - ריבוי חוטים כשלעצמו לא מאפשר הפעלת התוכנה על יותר משרת אחד)
 
מצד שני, מורכבות השימוש בריבוי חוטים - משתנה בין מקומות שונים ובין תעשיות שונות. יש תחומים שבהם יש הרבה חוטים שעובדים על מבני נתונים משותפים שמשתנים תדירות במהלך הריצה - וצריכים הרבה תאום ביניהם. יש תחומים שבהם החוטים עובדים בעיקר בצורה של pipeline - כל חוט מקבל משימה מתוך תור, מעבד אותה, ומעביר לתור של חוט אחר להמשך ביצוע - ללא עבודה על מבני נתונים משותפים מעבר לתור המשימות של כל חוט.
 
הצורה האחרונה היא ככל הנראה מאוד שכיחה במערכות משובצות ומערכות זמן אמת בעלי משאבי זכרון וכח מיחשוב נמוכים יחסית (לפחות על פי מה שאנשים שמגיעים משם מתארים בראיונות עבודה) - בין אם בתוכנה שרצה בתוך טיל, תוכנה שרצה בתוך טלפון שולחני וכן הלאה.
