www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dtl - yamu (yet another mintl update)

reply Ben Hinkle <bhinkle4 juno.com> writes:
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
Sep 02 2004
next sibling parent "antiAlias" <fu bar.com> writes:
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
Sep 02 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Sep 03 2004
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
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?  

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

Sep 03 2004
parent reply Sean Kelly <sean f4.ca> writes:
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
Sep 03 2004
parent Ben Hinkle <Ben_member pathlink.com> writes:
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.
Sep 04 2004