On Friday, 11 October 2013 at 02:07:57 UTC, Andrei Alexandrescu wrote:
>
> TDPL describes how synchronized automatically peels off the "shared" off of direct members of the object. Unfortunately that feature is not yet implemented.

This would help a ton.  I'm still not super happy about having to label an entire method as synchronized for this to work though.  I'd prefer to label it shared and synchronize only the part(s) inside that need to hold the lock.

On Friday, 11 October 2013 at 17:46:01 UTC, Sean Kelly wrote:
> The thing with locks is that you need to use the same lock for all accesses to a set of mutated data or atomicity isn't guaranteed.  And if you're locking externally you don't know what might change inside a class during a method call, so you have to use the same lock for all operations on that object, regardless of what you're doing.  At that point you may as well just synchronize on the class itself and be done with it.  So sure, it saves you from having to define shared or synchronized methods, but I don't think this should be how we want to write concurrent code in D.

How can one possibly used "synchronized" for this in absence of classes if desire behavior is to lock an entity, not statement block?

On Friday, 11 October 2013 at 17:49:11 UTC, Sean Kelly wrote:
> On Friday, 11 October 2013 at 02:07:57 UTC, Andrei Alexandrescu wrote:
>>
>> TDPL describes how synchronized automatically peels off the "shared" off of direct members of the object. Unfortunately that feature is not yet implemented.
>
> This would help a ton.  I'm still not super happy about having to label an entire method as synchronized for this to work though.  I'd prefer to label it shared and synchronize only the part(s) inside that need to hold the lock.

It should work as well with

synchronized(stuff) {
// Stuff get its first level sharing removed.
}

On Friday, 11 October 2013 at 17:54:12 UTC, deadalnix wrote:
> It should work as well with
>
> synchronized(stuff) {
> // Stuff get its first level sharing removed.
> }

I still stand by the point that for guaranteed safety it must be not simply removed but replaced with `scope` (assuming it is finally implemented).

On Friday, 11 October 2013 at 09:56:10 UTC, Leandro Lucarella wrote:
>
> This is not really what's stopping the porting, is a problem, but an independent one. My idea was to port the GC as it is in Tango, and then see how to overcome its limitations.

I tried this a while back, but the GC in Druntime has changed a bunch since it diverged from Tango, and some or all of those changed need to be applied to your concurrent collector before it can be used.  Like you, I ended up not having the time for this.  I think you'd need to do a diff of the current GC code vs. the code as it was originally checked into SVN on DSource.

On Friday, 11 October 2013 at 17:50:26 UTC, Dicebot wrote:
>
> How can one possibly used "synchronized" for this in absence of classes if desire behavior is to lock an entity, not statement block?

I'm not sure I follow.  But I was in part objecting to the use of synchronized without a related object:

synchronized {
    // do stuff
}

This statement should be illegal.  You must always specify a synchronization context:

synchronized(myMutex) {
    // do stuff
}

For the rest, it seemed like the suggestion was that you could just wrap a statement in any old synchronized block and all your problems would be solved, which absolutely isn't the case.

On Friday, 11 October 2013 at 18:05:00 UTC, Sean Kelly wrote:
> On Friday, 11 October 2013 at 17:50:26 UTC, Dicebot wrote:
>>
>> How can one possibly used "synchronized" for this in absence of classes if desire behavior is to lock an entity, not statement block?
>
> I'm not sure I follow.  But I was in part objecting to the use of synchronized without a related object:
>
> synchronized {
>     // do stuff
> }
>
> This statement should be illegal.  You must always specify a synchronization context:
>
> synchronized(myMutex) {
>     // do stuff
> }
>
> For the rest, it seemed like the suggestion was that you could just wrap a statement in any old synchronized block and all your problems would be solved, which absolutely isn't the case.


I was reading this : http://dlang.org/statement.html#SynchronizedStatement

It says that Expression in sync statement must evaluate to Object or interface and mutex get created specifically for it. But what if I want to use struct in that block? Or array?

On Friday, 11 October 2013 at 18:10:27 UTC, Dicebot wrote:
>
> I was reading this : http://dlang.org/statement.html#SynchronizedStatement
>
> It says that Expression in sync statement must evaluate to Object or interface and mutex get created specifically for it. But what if I want to use struct in that block? Or array?

Synchronize on a dummy object or use core.sync.mutex:

auto m = new Mutex;
synchronized(m) {

}

It's effectively the same as in C++ except that synchronized saves you the trouble of using an RAII scoped_lock variable.

On Friday, 11 October 2013 at 18:10:27 UTC, Dicebot wrote:
>
> I was reading this : http://dlang.org/statement.html#SynchronizedStatement
>
> It says that Expression in sync statement must evaluate to Object or interface and mutex get created specifically for it. But what if I want to use struct in that block? Or array?

Synchronize on a dummy object or use core.sync.mutex:

auto m = new Mutex;
synchronized(m) {

}

It's effectively the same as in C++ except that synchronized saves you the trouble of using an RAII scoped_lock variable.

On Friday, 11 October 2013 at 18:18:45 UTC, Sean Kelly wrote:
> On Friday, 11 October 2013 at 18:10:27 UTC, Dicebot wrote:
>>
>> I was reading this : http://dlang.org/statement.html#SynchronizedStatement
>>
>> It says that Expression in sync statement must evaluate to Object or interface and mutex get created specifically for it. But what if I want to use struct in that block? Or array?
>
> Synchronize on a dummy object or use core.sync.mutex:
>
> auto m = new Mutex;
> synchronized(m) {
>
> }
>
> It's effectively the same as in C++ except that synchronized saves you the trouble of using an RAII scoped_lock variable.

Yeah, but it can't possibly work in conjunction with proposed "shared" stripping inside the block, can it?