On Wednesday, 8 July 2015 at 21:15:19 UTC, deadalnix wrote:
On Wednesday, 8 July 2015 at 12:08:37 UTC, Jonathan M Davis
wrote:
I know that there are a number of people who get frustrated
with shared and using __gshared instead, but unless you fully
understand what you're doing and how the language works, and
you're _really_ careful, you're going to shoot yourself in the
foot it subtle ways if you do that.
- Jonathan M Davis
Amen
What sort of subtle ways? Can you give examples that are not
effectively the same subtle ways you would encounter with
pthreads in C/C++? I have been running with the assumption that
__gshared effectively bypasses TLS, which again, feels sort of
dirty to use a __ prefixed keyword for that, but, yeah...
I'm not sure why I don't see the magic with synchronized classes.
To me, they have a fundamental flaw in the fact they are classes.
While I don't mind much their existence, I would very much
dislike if that is the only convenient way to use the
shared/synchronized mechanisms.
Regarding your point about multiple pieces of data being guarded
by multiple mutexes using the proposed design, we could perhaps
do it this way:
@lock(mutex) shared {
int moo;
float foo;
}
We could implement synchronized classes/structs like this:
struct Foo {
void cowsay() synchronized(moootex) {
// your synchronized method implementation
}
void cowsay() {
synchronized(mootex) {
// no sugar
}
}
@lock(moootex) private shared {
int m_moo;
float m_foo;
}
}
I think we should have avoid Java's non-sense of having to
declare a class to do anything, and instead find generic ways to
do things that are useful for multiple paradigms.
