[
https://issues.apache.org/jira/browse/GEODE-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17275236#comment-17275236
]
ASF subversion and git services commented on GEODE-8887:
--------------------------------------------------------
Commit 78d2fbf67e81152b1a61a4ac411a30121e9f87ce in geode-native's branch
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=78d2fbf ]
GEODE-8887: Refactor EventIdTSS class (#733)
- Use Meyers singleton pattern for global singleton (threadId), and
thread local singleton EventIdTSS
- rename all member variables in EventId and EventIdTSS classes
- clean up logic slightly around global threadId atomic var
- rename EventId getter methods for clarity
> Switch EventId thread and sequence logic to Meyers singleton pattern
> --------------------------------------------------------------------
>
> Key: GEODE-8887
> URL: https://issues.apache.org/jira/browse/GEODE-8887
> Project: Geode
> Issue Type: Improvement
> Components: native client
> Reporter: Blake Bender
> Assignee: Blake Bender
> Priority: Major
> Labels: pull-request-available
>
> As a developer, I need to be able to rely on the order of initialization of
> my global and/or thread local singleton objects, in order to reasonably
> expect things to work that count on said objects. The current EventIdTSS
> implementation doesn't use Meyers singleton, and thus the order of
> initialization shows up seriously different from what you'd imagine. In
> particular, the thread local EventIdTSS object _appears_ to be initialized
> long before it is used on each thread, _and_ many of the threads the NC spins
> up will _never_ use it, leaving us with a couple of dozen or more extra
> copies of this thing lying around. Switching to the standard C++ singleton
> pattern will make this code a lot more deterministic, in addition to much
> more readable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
