Mike Clark wrote:
Oleg Kalnichevski wrote:
sebb wrote:
For example, I used to work on Alpha systems, and writes to the main
memory from one CPU could be seen in a different order on another CPU.
[I understand this was done for performance reasons.]
So a thread on one CPU only sees the correct data if both CPUs issue
the appropriate memory barrier instructions in the correct order.
I only have experience programming in x86 assembly, so I am not in a
position to judge. However, this is indeed the case, we should drop
any pretense those classes could be used by multiple threads and
simply declare them thread-unsafe.
Are instances of these classes limited to single threads in the current
codebase?
Yes, they are. AbstractHttpMessage instantiates BasicHttpParams, which
is not a problem, because the class is not thread-safe anyways. All
other classes use interfaces, not concrete implementations.
Does that need to be reviewed to be confirmed?
Extra code review never hurts.
Is there any foreseeable need to have instances of these classes shared
between threads?
In HttpClient, yes. Both parameters and protocol interceptors can be set
at the client level and then used by multiple request execution threads.
Oleg
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
