You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "James Peach (JIRA)" <ji...@apache.org> on 2016/08/16 20:56:21 UTC

[jira] [Commented] (TS-3236) Simplify usage around TS_HAS_128BIT_CAS and freelist items

    [ https://issues.apache.org/jira/browse/TS-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423367#comment-15423367 ] 

James Peach commented on TS-3236:
---------------------------------

With C++11 consider using std::atomic (IIRC there is a way to test whether std::atomic is actually using atomics).

> 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: 8.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)