[
https://issues.apache.org/jira/browse/TS-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3236:
------------------------------
Fix Version/s: (was: 6.2.0)
7.0.0
> Simplify usage around TS_HAS_128BIT_CAS and freelist items
> ----------------------------------------------------------
>
> Key: TS-3236
> URL: https://issues.apache.org/jira/browse/TS-3236
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Leif Hedstrom
> Assignee: Jason Kenny
> Labels: newbie
> Fix For: 7.0.0
>
>
> In various places of the code, we have patterns like
> {code}
> #if TS_HAS_128BIT_CAS
> result = ink_atomic_cas((__int128_t*) &m_log_buffer.data, old_h.data,
> tmp_h.data);
> #else
> result = ink_atomic_cas((int64_t *) &m_log_buffer.data, old_h.data,
> tmp_h.data);
> #endif
> {code}
> This is rather unfortunate IMO, since it means it's fairly easy to make a
> mistake such that the wrong CAS operator is used. I see at least two options:
> 1) Remove the check entirely, and always assume we have a 128-bit CAS
> available?
> 2) Add some typedef'ery around the code, such that only the core (queue)
> implementation needs to know about 64-bit vs 128-bit CAS. So the above would
> be eliminated to use a single ink_atomic_cas() without type casting.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
