"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:d77epc$1p5d$1@digitaldaemon.com...
>>> Ben, this is really good spec. - I like it. If you need co-developer for this project please do not hesitate to contact me.
>>
>> cool - thanks. Right now I'm shuffling the earlier class code around to
>> fit the new structure. I'll try to put something up quickly so that you
>> can take some of the load. Once I have some basics would you want to
>> write
>> the thread-safe wrappers? I'm picturing something like the helper
>
> My opinion is that MinTL should be _completely_ thread-safe by default.
> Reason for this is simple fact that in few years almost all home computers
> will most likely have two processors (or two cores) . Even nowadays
> processors have some threading features (HT from Intel for example).
> So IT population will just be more and more focused on multithreading.

That's what Sun thought when they first wrote the JDK. Now all the thread-safe containers like Vector and Hashtable are deprecated and replaced with non-threadsafe versions. One reason is that often just making the get/set calls threadsafe isn't the right level of granularity. Typically if you traverse a vector or perform some complex operation you want to lock the container during the whole loop and not just on every get/set. The other big reason Vector isn't used anymore is speed - the non-synchronized version is just faster. Thread safety should be required infrequently enough that the wrappers don't make the system unmaintainable.

of course YMMV - it all depends on the application.

FWIW: I think Ben is right on the mark here ~ particularly so regarding the "granularity" aspect. Thread-safety is an important issue, but insisting everyone should always pay that "tax" is not necessarily the right answer.


"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d77gdf$1qm1$1@digitaldaemon.com...
>
> "Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:d77epc$1p5d$1@digitaldaemon.com...
> >>> Ben, this is really good spec. - I like it. If you need co-developer
for
> >>> this project please do not hesitate to contact me.
> >>
> >> cool - thanks. Right now I'm shuffling the earlier class code around to
> >> fit the new structure. I'll try to put something up quickly so that you
> >> can take some of the load. Once I have some basics would you want to
> >> write
> >> the thread-safe wrappers? I'm picturing something like the helper
> >
> > My opinion is that MinTL should be _completely_ thread-safe by default. Reason for this is simple fact that in few years almost all home
computers
> > will most likely have two processors (or two cores) . Even nowadays processors have some threading features (HT from Intel for example). So IT population will just be more and more focused on multithreading.
>
> That's what Sun thought when they first wrote the JDK. Now all the thread-safe containers like Vector and Hashtable are deprecated and
replaced
> with non-threadsafe versions. One reason is that often just making the get/set calls threadsafe isn't the right level of granularity. Typically
if
> you traverse a vector or perform some complex operation you want to lock
the
> container during the whole loop and not just on every get/set. The other
big
> reason Vector isn't used anymore is speed - the non-synchronized version
is
> just faster. Thread safety should be required infrequently enough that the wrappers don't make the system unmaintainable.
>
> of course YMMV - it all depends on the application.
>
>

A lot of those ideas sound great, but why DequeQueue and DequeStack? They only need insertions at one end, so I don't understand the advantages of using a deque. However, I do like the idea of having Array&Stack versions.

In article <d6ri5c$90$1@digitaldaemon.com>, Ben Hinkle says...
>
>Well I've started to explode the class and interface list to be more standard. The squished hierarchy wasn't wearing very well. I'm also testing names without I or C prefixes and using the package to distinguish the classes from the structs. Note I'm leaning towards keeping slicing and anything that returns collections to be in the class hierarchy instead of the interface hierarchy so that covariance will work. That is, if the slice of an AbstractList is an AbstractList then the slice of a LinkedList can be a LinkedList.
>
>/**  Interface Hierarchy
> *
> *   Enumeration(Value)
> *     IndexedEnumeration(Index,Value)
> *
> *   Container(Value) : Enumeration(Value)
> *     AssocContainer(Key,Value) : IndexedEnumeration(Key,Value)
> *     List(Value) : IndexedEnumeration(size_t,Value)
> *     Set(Value)
> *     MultiSet(Value)
> *     Stack(Value)
> *     Queue(Value)
> */
>
>/**  Class Hierarchy
> *
> *  AbstractContainer(Value) : Container!(Value)
> *    AbstractAA(Key,Value) : AssocContainer(Key,Value)
> *      ConcurrentAA
> *      HashTable
> *      SortedAA
> *      LinkedAA
> *    AbstractList(Value) : List(Value)
> *      LinkedList
> *      ArrayList
> *      Deque
> *      CircularList
> *      SList
> *      CircularSList
> *    AbstractSet(Value) : Set(Value)
> *      HashSet
> *      SortedSet
> *      LinkedSet
> *    AbstractMultiSet(Value) : MultiSet(Value)
> *      HashMultiSet
> *      SortedMultiSet
> *      LinkedMultiSet
> *    AbstractStack(Value) : Stack(Value)
> *      ArrayStack
> *      DequeStack
> *      LinkedStack
> *    AbstractQueue(Value) : Queue(Value)
> *      ArrayQueue
> *      DequeQueue
> *      LinkedQueue
> *      PriorityQueue
> */
>
>

Pardon me, I meant I like the idea of Array & Linked list versions of stacks and queues (not a stack version :P ). Also, how will you implement LinkedSet, LinkedMultiSet, and LinkedAA?

In article <dei1vq$2vat$1@digitaldaemon.com>, Ben Phillips says...
>
>A lot of those ideas sound great, but why DequeQueue and DequeStack? They only need insertions at one end, so I don't understand the advantages of using a deque. However, I do like the idea of having Array&Stack versions.
>
>In article <d6ri5c$90$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>Well I've started to explode the class and interface list to be more standard. The squished hierarchy wasn't wearing very well. I'm also testing names without I or C prefixes and using the package to distinguish the classes from the structs. Note I'm leaning towards keeping slicing and anything that returns collections to be in the class hierarchy instead of the interface hierarchy so that covariance will work. That is, if the slice of an AbstractList is an AbstractList then the slice of a LinkedList can be a LinkedList.
>>
>>/**  Interface Hierarchy
>> *
>> *   Enumeration(Value)
>> *     IndexedEnumeration(Index,Value)
>> *
>> *   Container(Value) : Enumeration(Value)
>> *     AssocContainer(Key,Value) : IndexedEnumeration(Key,Value)
>> *     List(Value) : IndexedEnumeration(size_t,Value)
>> *     Set(Value)
>> *     MultiSet(Value)
>> *     Stack(Value)
>> *     Queue(Value)
>> */
>>
>>/**  Class Hierarchy
>> *
>> *  AbstractContainer(Value) : Container!(Value)
>> *    AbstractAA(Key,Value) : AssocContainer(Key,Value)
>> *      ConcurrentAA
>> *      HashTable
>> *      SortedAA
>> *      LinkedAA
>> *    AbstractList(Value) : List(Value)
>> *      LinkedList
>> *      ArrayList
>> *      Deque
>> *      CircularList
>> *      SList
>> *      CircularSList
>> *    AbstractSet(Value) : Set(Value)
>> *      HashSet
>> *      SortedSet
>> *      LinkedSet
>> *    AbstractMultiSet(Value) : MultiSet(Value)
>> *      HashMultiSet
>> *      SortedMultiSet
>> *      LinkedMultiSet
>> *    AbstractStack(Value) : Stack(Value)
>> *      ArrayStack
>> *      DequeStack
>> *      LinkedStack
>> *    AbstractQueue(Value) : Queue(Value)
>> *      ArrayQueue
>> *      DequeQueue
>> *      LinkedQueue
>> *      PriorityQueue
>> */
>>
>>
>
>