Graham St Jack wrote:
> Priority inheritance chaining goes like this:
>
> Thread low locks mutex A, then mutex B
>
> Thread high tries to lock mutex B, elevating low's priority to high's so
> that high can get the mutex quickly.
>
> When thread low releases mutex B (letting high get it), the OS
On 23/07/10 10:23, Sean Kelly wrote:
awishformore Wrote:
On 22/07/2010 01:49, Robert Jacques wrote:
Have you tried core.sync.rwmutex? Also, please remember that CREW locks
are not composable and can easily lead to dead-locks.
Afaik, the current rwmutex is a wrapper around tw
awishformore Wrote:
> On 22/07/2010 01:49, Robert Jacques wrote:
> >
> > Have you tried core.sync.rwmutex? Also, please remember that CREW locks
> > are not composable and can easily lead to dead-locks.
>
> Afaik, the current rwmutex is a wrapper around two separate mutexes (one
> for readers, o
On 22/07/2010 01:49, Robert Jacques wrote:
On Tue, 20 Jul 2010 15:41:31 -0400, Brian Palmer
wrote:
> It probably wasn't very clear from my simplified example, but I'm
looking to create a shared-reader-one-writer scenario. If I declare
MyValue synchronized, only one thread can be inside the get
Robert Jacques Wrote:
> On Tue, 20 Jul 2010 15:41:31 -0400, Brian Palmer
>
> wrote:
>
> >> > It probably wasn't very clear from my simplified example, but I'm
> >> looking to create a shared-reader-one-writer scenario. If I declare
> >> MyValue synchronized, only one thread can be inside
The core stuff is in a different repository, and I haven't done all the
work to integrate the docs yet. I sent a file to do most of this to the
Phobos list though, if you're inclined to track it down.
Brian Palmer wrote:
> Thanks Sean, it's great to at least know where the issue is. As to my
> o
On Tue, 20 Jul 2010 15:41:31 -0400, Brian Palmer
wrote:
> It probably wasn't very clear from my simplified example, but I'm
looking to create a shared-reader-one-writer scenario. If I declare
MyValue synchronized, only one thread can be inside the get() method at
a time, which defeats th
> > It probably wasn't very clear from my simplified example, but I'm looking
> > to create a shared-reader-one-writer scenario. If I declare MyValue
> > synchronized, only one thread can be inside the get() method at a time,
> > which defeats the shared-reader requirement. Imagine this is a muc
Thanks Sean, it's great to at least know where the issue is. As to my other
question, why do the D std library docs at
http://www.digitalmars.com/d/2.0/phobos/phobos.html have no indication that
core.sync and the other core.* packages even exist? Are the APIs not stable
enough yet to treat them
On Sun, 18 Jul 2010 16:05:08 +, Sean Kelly wrote:
> Graham St Jack wrote:
>> On Sat, 17 Jul 2010 11:42:03 -0400, Sean Kelly wrote:
>>
>>> The casts are necessary because I haven't yet applied 'shared' to
>>> druntime. I ran into a few issues when doing so and rolled back my
>>> changes. I'
Graham St Jack Wrote:
>
> The code I am trying to write is a simple synchronized class with a
> Condition, but I can't create a Condition on a shared "this".
>
> A cut-down version of what I want to write is:
>
> synchronized class Foo {
> Condition mCondition;
> this() {
> mCondition =
Graham St Jack wrote:
> On Sat, 17 Jul 2010 11:42:03 -0400, Sean Kelly wrote:
>
>> The casts are necessary because I haven't yet applied 'shared' to
>> druntime. I ran into a few issues when doing so and rolled back my
>> changes. I'll give it another shot before the next release.
>
> I'm glad
On Sat, 17 Jul 2010 11:42:03 -0400, Sean Kelly wrote:
> The casts are necessary because I haven't yet applied 'shared' to
> druntime. I ran into a few issues when doing so and rolled back my
> changes. I'll give it another shot before the next release.
I'm glad you announced you intention - I w
The casts are necessary because I haven't yet applied 'shared' to druntime. I
ran into a few issues when doing so and rolled back my changes. I'll give it
another shot before the next release.
> It probably wasn't very clear from my simplified example, but I'm looking to
> create a shared-reader-one-writer scenario. If I declare MyValue
> synchronized, only one thread can be inside the get() method at a time, which
> defeats the shared-reader requirement. Imagine this is a much larger
It probably wasn't very clear from my simplified example, but I'm looking to
create a shared-reader-one-writer scenario. If I declare MyValue synchronized,
only one thread can be inside the get() method at a time, which defeats the
shared-reader requirement. Imagine this is a much larger more co
I am few days old in playin with D2 and whole shared stuff, so I am probably
wrong in something.
You should probably declare your example class MyValue synchronized instead of
shared. It implies that class is shared too, and this way all methods are
synchronized. In D1 you could mix synchroniz
This is really like 3 messages, but I didn't want to spam the list with topics,
and maybe I'm the only one feeling this pain anyway. So first: from the
perspective of a guy who has dabbled in D1 and D2 for years, but hasn't looked
closed at the language in ~10 months, I loved TDPL. It convinced
18 matches
Mail list logo