Защита локального хранилища потока от других потоков

Вы правы, полагая, что программист может получить доступ к локальной памяти потока другого потока в рамках того же процесса. Это было бы нетривиально, поскольку программисту пришлось бы либо напрямую обращаться к памяти, либо использовать некоторые недокументированные API, но теоретически это можно было бы сделать. Но зачем ему (или ей) ?! Основная идея TLS состоит в том, чтобы упростить программистам хранение данных в месте, которое не используется совместно с другими потоками в процессе.

Тот факт, что локальное хранилище потока управляется ОС, означает, что фактическое расположение локального хранилища потока в памяти процесса напрямую не объявляется. Чтение и запись в TLS «управляется» операционной системой с относительно низкими накладными расходами (вызов функции) путем предоставления простого API Get / Set. Защита здесь в основном заключается в удобстве, поскольку затрудняет случайный доступ к данным, принадлежащим (также доступным) другому потоку.

Не требует механизма защиты. Фактически, защитный механизм только усложнит задачу. Например, предположим, что поток хочет отсортировать один из своих объектов, поэтому он передает его методу сортировки. Что произойдет, если этот метод сортировки использует несколько потоков «под капотом» для сортировки?

Итак, ваш вопрос основан на совершенно ложной предпосылке. Такой механизм защиты означал бы, что каждый метод, работающий с объектом, должен был бы объявлять, безопасно ли работать с данными, зависящими от потока, что было бы кошмаром.