View mode: basic / threaded / horizontal-split · Log in · Help
September 03, 2004
yamu (yet another mintl update)
In anticipation of adding more of Doug Lea's concurrent containers, I've
added a companion library to mintl to the mintl.zip file. The companion
library is a set of locks and synchronization constructs (also from Doug
Lea, hmmmm...). It basically just has locks, condition variables and a few
nifty helpers like a count-down latch, a semaphore, a cyclic barrier and a
read-write lock. Besides that I added a heap to mintl proper (a heap is an
array where x[n] is greater than x[2*n+1] and x[2*n+2]). Heaps are
typically used to implement priority queues.

usual site
http://home.comcast.net/~benhinkle/mintl/
The locks library documentations is at
http://home.comcast.net/~benhinkle/mintl/locks.html
but you can also get to that page from the main mintl page so don't worry if
you lose that.

I'll get back to this after the long weekend so expect more late next week
or even the week after that.

-Ben
September 03, 2004
Re: yamu (yet another mintl update)
May I comment that I really like what you're doing with this library, Ben?
It's simple, familiar, and straightforward. A minor quibble would be the
lack of examples for complete newbies.

I wonder if someone else would be willing to take on documentation tasks
like that? Surely there are some capable writers amongst the NG
participants, who'd like to contribute also ... ?

- Kris



"Ben Hinkle" <bhinkle4@juno.com> wrote in message
news:ch8pl1$12gs$1@digitaldaemon.com...
In anticipation of adding more of Doug Lea's concurrent containers, I've
added a companion library to mintl to the mintl.zip file. The companion
library is a set of locks and synchronization constructs (also from Doug
Lea, hmmmm...). It basically just has locks, condition variables and a few
nifty helpers like a count-down latch, a semaphore, a cyclic barrier and a
read-write lock. Besides that I added a heap to mintl proper (a heap is an
array where x[n] is greater than x[2*n+1] and x[2*n+2]). Heaps are
typically used to implement priority queues.

usual site
http://home.comcast.net/~benhinkle/mintl/
The locks library documentations is at
http://home.comcast.net/~benhinkle/mintl/locks.html
but you can also get to that page from the main mintl page so don't worry if
you lose that.

I'll get back to this after the long weekend so expect more late next week
or even the week after that.

-Ben
September 03, 2004
Re: yamu (yet another mintl update)
In article <ch8pl1$12gs$1@digitaldaemon.com>, Ben Hinkle says...
>
>In anticipation of adding more of Doug Lea's concurrent containers, I've
>added a companion library to mintl to the mintl.zip file. The companion
>library is a set of locks and synchronization constructs (also from Doug
>Lea, hmmmm...).

Is this a direct inclusion of the "concurrent" project?  And does this mean that
project is still on track?  I saw the that there hadn't been any updates in the
past few months and wondered...  Assuming it is, that's fantastic.  The stuff
that's there should be more than enough to get started, though it would be nice
to have a scoped lock wrapper:

# auto class ScopedLock
# { 
# public:
#     this( Lock l ) { lock = l; lock.lock(); }
#     ~this() { lock.unlock(); }
# private:
#     Lock lock;
# }


Sean
September 04, 2004
Re: yamu (yet another mintl update)
In article <chaflk$1tdm$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <ch8pl1$12gs$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>In anticipation of adding more of Doug Lea's concurrent containers, I've
>>added a companion library to mintl to the mintl.zip file. The companion
>>library is a set of locks and synchronization constructs (also from Doug
>>Lea, hmmmm...).
>
>Is this a direct inclusion of the "concurrent" project?  

the locks stuff is about 1/3 of the concurrent library. The zip file for
concurrent hasn't been updated in a while but the repository has pretty much
what I put into mintl.zip. The differences are in module names, help formatting
and the different compare-and-set functions.

>And does this mean that project is still on track?  
I guess so - though I think concurrent is pretty much done except for the
containers part and that was partly why I started up on mintl. Mike had been
working on the lightweight fork/join threading classes but when Doug recommended
we go to the JSR166 codebase I don't know if Mike lost steam. That was probably
my fault for wasting time with Dougs original code.

>I saw the that there hadn't been any updates in the
>past few months and wondered...  Assuming it is, that's fantastic.  The stuff
>that's there should be more than enough to get started, though it would be nice
>to have a scoped lock wrapper:
>
># auto class ScopedLock
># { 
># public:
>#     this( Lock l ) { lock = l; lock.lock(); }
>#     ~this() { lock.unlock(); }
># private:
>#     Lock lock;
># }

neat idea - I will think about that. I wonder, though, about auto with locks
since auto variables live on one stack and threads live across stacks - so how
would one thread know about another thread's auto lock? will ponder that one...

>
>Sean
>
>
September 04, 2004
Re: yamu (yet another mintl update)
In article <chb7fe$24sp$1@digitaldaemon.com>, Ben Hinkle says...
>>
>># auto class ScopedLock
>># { 
>># public:
>>#     this( Lock l ) { lock = l; lock.lock(); }
>>#     ~this() { lock.unlock(); }
>># private:
>>#     Lock lock;
>># }
>
>neat idea - I will think about that. I wonder, though, about auto with locks
>since auto variables live on one stack and threads live across stacks - so how
>would one thread know about another thread's auto lock? will ponder that one...

It shouldn't have to.  The class is intended to use RAII to avoid the need for
explicit calls to unlock in "finally" or "catch" blocks.  Entering threads would
wait on the lock just as if the auto class weren't there, since the auto class
just forwards all the work to the underlying lock anyway.

Sean
September 04, 2004
Re: yamu (yet another mintl update)
In article <chb9c4$25dv$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <chb7fe$24sp$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>># auto class ScopedLock
>>># { 
>>># public:
>>>#     this( Lock l ) { lock = l; lock.lock(); }
>>>#     ~this() { lock.unlock(); }
>>># private:
>>>#     Lock lock;
>>># }
>>
>>neat idea - I will think about that. I wonder, though, about auto with locks
>>since auto variables live on one stack and threads live across stacks - so how
>>would one thread know about another thread's auto lock? will ponder that one...
>
>It shouldn't have to.  The class is intended to use RAII to avoid the need for
>explicit calls to unlock in "finally" or "catch" blocks.  Entering threads would
>wait on the lock just as if the auto class weren't there, since the auto class
>just forwards all the work to the underlying lock anyway.

oh ok, now I get it. I was being dense. For some reason I completely ignored the
lock being passed into the ScopedLock constructor :P
So it is just like the synchronized statement except for Locks instead of object
monitors. I like that. I will definitely add it - maybe right in the lock.d
module after the interface for Lock.
Top | Discussion index | About this forum | D home