On Tuesday, 15 October 2013 at 18:57:16 UTC, Sean Kelly wrote:
> Perhaps I missed it from skimming, but why are we using atomic operations here anyway?  Has testing revealed that it's necessary?

I presume you don't mean running some code and then seeing if it breaks as a test to see if atomic operation are necessary?

Synchronisation *must* be done by design.

On Tuesday, 15 October 2013 at 19:51:00 UTC, John Colvin wrote:
> On Tuesday, 15 October 2013 at 18:57:16 UTC, Sean Kelly wrote:
>> Perhaps I missed it from skimming, but why are we using atomic operations here anyway?  Has testing revealed that it's necessary?
>
> I presume you don't mean running some code and then seeing if it breaks as a test to see if atomic operation are necessary?
>
> Synchronisation *must* be done by design.

Well sure, but why not use a Mutex?  What does trying to sort out a correct lock-free algorithm gain us here?

On Tue, 15 Oct 2013 20:57:14 +0200, Sean Kelly wrote:

> Perhaps I missed it from skimming, but why are we using atomic operations here anyway?  Has testing revealed that it's necessary?

I believe it is the "why make it easy when we can make it complicated?" approach...

>
> So, here are your revised version:
> https://github.com/phobos-x/phobosx/blob/1f0016c84c2043da0b9d2dafe65f54fcf6b6b8fa/source/phobosx/signal.d
>
> Sorry, but you are making the same mistake again.

Yeah, I made a mistake again. In my mind it was ok because "o" is read from a shared variable, but this is not true, as it is read from a temporary, which does not hold a visible address.

It is getting embarrassing, but I really appreciate your help in making it a rock solid solution. Thank you! I hope my next try is working out better, I have to sleep over it and re-examine it, but maybe you want to have a look, you are usually faster and more reliable in finding flaws than myself ;-) :

https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d

The relevant code is now in InvisibleRef.address and InvisibleRef.makeVisible/makeInvisible.

Best regards,

Robert

> Well sure, but why not use a Mutex?  What does trying to sort out a correct lock-free algorithm gain us here?

It is not about concurrency for general purpose (phobosx.signal is no more thread safe than std.signals), but for the GC. A reference is hidden from the GC, when making it visible again you get a race condition with the GC. Ensuring that you really have a valid reference proves to be troublesome.

The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems.

Best regards,

Robert

See also: http://d.puremagic.com/issues/show_bug.cgi?id=4150

Best regards,

Robert

On 10/13/2013 11:24 PM, Denis Shelomovskij wrote:
> 13.10.2013 22:19, Walter Bright пишет:
>> On 10/13/2013 12:47 AM, Denis Shelomovskij wrote:
>>> --- Proposal ---
>>
>> Please post as a DIP:
>>
>> http://wiki.dlang.org/DIPs
>>
>> The trouble with it as a n.g. posting is they tend to scroll off and be
>> forgotten.
>
> Why? There is already enhancement request 4151 to no forget and review queue to
> add it into.


http://d.puremagic.com/issues/show_bug.cgi?id=4151 does not contain the info in your post starting this thread, nor does it contain any link to this thread.

On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote:
>
> The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems.

Gotcha.  Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive.  Why not work on a DIP to get them built in?  For example, one option might be to have the GC perform certain types of finalization while the world is stopped.  This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime.

On Tuesday, 15 October 2013 at 23:20:39 UTC, Sean Kelly wrote:
> On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote:
>>
>> The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems.
>
> Gotcha.  Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive.  Why not work on a DIP to get them built in?  For example, one option might be to have the GC perform certain types of finalization while the world is stopped.  This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime.

That makes a lot of sense, +1!

16.10.2013 3:20, Sean Kelly пишет:
> On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote:
>>
>> The problem is that destructors and thus the registered hooks for the
>> dispose events are called when threads are already resumed. If this
>> wasn't the case there would actually be no problems.
>
> Gotcha.  Looking at the code... I think you'll get this to work, but
> manipulating such user-mode weak references seems really expensive.  Why
> not work on a DIP to get them built in?  For example, one option might
> be to have the GC perform certain types of finalization while the world
> is stopped.  This would have to be limited to very rudimentary stuff,
> and the easiest way to guarantee that would be to have everything live
> in Druntime.

But someone have to do it. And I can only see it will save one of two GC lock/unlock pairs.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij