www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10165] New: No syntax to create thread-local shared variables

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165

           Summary: No syntax to create thread-local shared variables
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: pull
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: GenericNPC gmail.com


--- Comment #0 from IdanArye <GenericNPC gmail.com> 2013-05-24 14:22:39 PDT ---
Writing

    class Foo
    {
        shared Foo a;
        static Foo b;
        static shared Foo c;
    }

`a` is an instance-local shared reference. `b` is a thread-local not-shared
reference. You would expect that `c` would be thread-local shared reference -
but instead it's a process-global shared reference.

I do not suggest changing the behaviour of `static shared` - it is the syntax
for process-global shared variables by design, and changing it will break too
much code. But we do need a way to create thread-local shared variables.

I've implemented a library solution, but I believe this problem requires a
compiler solution that's why the component field is "dmd".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 24 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com


--- Comment #1 from Steven Schveighoffer <schveiguy yahoo.com> 2013-05-24
14:30:04 PDT ---
I'm almost positive this works:

static shared(Foo) a;

That is, if shared is interpreted as a storage class, it puts the variable in
global storage, not thread local.  But shared as a type constructor just
affects the type.

Don't have the patience to test, so I'll leave the bug open :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165



--- Comment #2 from IdanArye <GenericNPC gmail.com> 2013-05-24 14:43:55 PDT ---
Here is the pull request:
https://github.com/D-Programming-Language/phobos/pull/1302

 Steven Schveighoffer: It doesn't work - `static shared(T)` does the same as
`static shared T`.

I assume the proper solution would be to fix this, but I leave the pull request
open anyways. Like I said - there should be a compiler solution - but we don't
know how many people use the `static shared(T)` syntax with the intention of
declaring a process-global variable, and we can't show a warning message when
this syntax is used wrongly - so the dmd solution requires some serious debate.
In the meanwhile, the Phobos solution doesn't break anything, and it took me 20
minutes: 1 for the implementation, 2 for the unit test, and the rest for all
the "paperwork"(=sending this bug and the pull request) - so I planned from the
beginning to send it and let the dev team decide if they want to use my Phobos
solution or to fix it in dmd.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #3 from bearophile_hugs eml.cc 2013-05-24 15:22:55 PDT ---
(In reply to comment #2)

 and let the dev team decide if they want to use my Phobos
 solution or to fix it in dmd.
Where possible in D we prefer to fix the language to help all future D programmer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com


--- Comment #4 from Walter Bright <bugzilla digitalmars.com> 2013-05-24
15:42:00 PDT ---
(In reply to comment #0)
  But we do need a way to create thread-local shared variables.
Why? What is the motivating example? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165



--- Comment #5 from IdanArye <GenericNPC gmail.com> 2013-05-24 16:22:30 PDT ---
(In reply to comment #4)
 (In reply to comment #0)
  But we do need a way to create thread-local shared variables.
Why? What is the motivating example?
I'm implementing the low lock singleton - http://forum.dlang.org/thread/pelhvaxwjzhehdjtpsav forum.dlang.org - as part of my `std.idioms` library - http://forum.dlang.org/thread/fofbrlqruxbevnxchxdp forum.dlang.org - in both `shared` and `__gshared` versions(I also have a thread-local(=`static`) version, but it doesn't use the low lock implementation) A small optimization in the implementation is instead of using a thread-local boolean indicator to determine if the singleton has been initialized yet, to save a thread-local reference to the actual instance object. That way, instead of accessing the memory twice(once to check the indicator and once to fetch the object) we only need to access it once. Now, doing it in the `__gshared` version was straight-forward, but the `shared` version posed a problem - the need to have a thread-local reference to a shared object - hence this bug report and pull request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165



--- Comment #6 from Walter Bright <bugzilla digitalmars.com> 2013-05-24
19:35:18 PDT ---
You can have a thread-local reference to a shared object:

    static shared(T)* p;

p is thread local, and it points to a shared instance of T.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 24 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10165


Dmitry Olshansky <dmitry.olsh gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh gmail.com


--- Comment #7 from Dmitry Olshansky <dmitry.olsh gmail.com> 2013-05-24
22:32:09 PDT ---
(In reply to comment #6)
 You can have a thread-local reference to a shared object:
 
     static shared(T)* p;
 
 p is thread local, and it points to a shared instance of T.
The bug report is about classes. With T* that would be double indirection. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013