primary downstream/client systems of SecDB

I’m sure over the years SecDB took on other roles but these are its usages recognized by business.

Business use different terms to describe the usage of SecDB. Many of these terms mean more or less the same.

1) risk
– stress test
– scenario analysis
– exposure analysis
– concentration risk

2) valuation/pricing for non-risk purposes (such as GL, EOD marking, RFQ?

objects (in addition to methods) on a call stack

In my previous java debugging experience, the call stack is often perceived as a stack of method calls. Since most of the methods are non-static, why don’t we care about the receiver (and caller) objects of these calls? I think it’s because we don’t need to.

Now, in multi-threaded, the objects making/receiving the calls are relevant.
* Frequently threads lock on those objects.
* Also the object states could get corrupt.
* wait/notify can use these objects as waiting rooms

See P287 of Doug Lea’s book.

boost thread — recursive, try-lock, reader/writer, timeout …

These lock features are implemented at different layers in Boost.

In java, Reentrance is the only option — all locks are recursive. Reader/writer lock is a feature built on top of the basic reentrant lock. tryLock and lock timeout are basic features of the Lock interface.

In Boost, those CONCEPTS, lock types, free functions, typedef are noises to a beginner;) Specifically, people say mutex objects are accessed not directly but through wrapper, but the wrappers add noise. Actually, core classes[1] are mutex and unique_lock. Both of them support try-locking. However, to understand our big 4 features, it’s cleaner to focus on the mutex classes —

* Try-lock — supported by all mutex classes
* Timed locking — supported by a subset of the mutex classes, namely timed_mutex and recursive_timed_mutex.
* Reader/writer — supported by exactly one mutex class, namely shared_mutex.
* Reentrance — supported by a subset of the mutex classes, namely recursive_mutex and recursive_timed_mutex. Note Reentrance is implemented by these 2 mutex classes only, and not in the Lockable concepts or those complicated lock types. Just scan the boost documentation.

Once we are clear on these features in the mutex classes, we can understand the structure among the Lockable CONCEPTS —

+ Try-lock — supported by all Lockable concepts.
+ Timed locking — TimedLockable and derivatives
+ Reader/writer — SharedLockable only.
(Reentrance — not in these concepts)

[1]How about the workhorse —> scoped_lock? Confusing to some novices, scoped_lock is a typedef of unique_lock

DAM issue in concurrent C++ apps

Q: how to avoid double-delete across threads?
%%A: Java solves the problem with a garbage collector. C++ Smart ptr can be designed to do the delete()  in a critical section.

Q: how to avoid reading a pointer on Thread A after Thread B deletes it?
%%A: with smart ptr, thread B won’t delete it.
A: Basic technique is a reference-counted smart pointer such as shared_ptr and rogue-wave smart pointers.

A technique is to give different mini-heaps to different threads, provided they don’t share heap objects.

c# enum is more like c++, less like java?

c++ enum is usually 16-bit but can be configured 8-bit in high-performance systems like market data feed.

java enum is very much like a class with static (singleton) fields. Nothing to do with integers. (perhaps implemented with integers.)

— c# enum is more like c++ IMO in terms of run time representation.
* No singleton. c# Enum objects are passed by value (pbclone), just like simple-type integers (which are physically struct objects)
* An enum Instance is usually 16-bit.
* An enum Type is always based on some integer type, slightly more flexible than c++
* For now, safely disregard the (confusing) fact that enum types extend System.Enum.

— C# enum is more like java enum in terms of compiler support.
A friend pointed out some differences between c# and c++ enums
$ c# value TYPES (not instances) have rich meta data. C++ enum is a simple int. No methods
$ c# enum type can customize ToString()


py introspection – speculation+observations

Background — Python’s 2 fundamental features, introspection and polymorphism, appear to be integrated (more than in other languages). You could add to the mix the “module” feature, but I won’t.

The __dict__ thingy seems to be the common theme (heart of everything python), but I found it hard to prove in code. For now, let’s take [[Programming python]] at face value.

Python introspection offers perhaps the best window into python internals. I guess introspection reveals
– polymorphism, inheritance,
– function call resolution (always run time)
– instance-method/class-method
– bound methods
– user defined functions and classes
– modules and namespaces

Here’s a limited sample of the numerous introspection features in python —
– __dict__
– __methods__, __members__
– dir()
– type()
– isinstance()
– __mro__

exactly why is a bond selling at a discount@@

…because this bond’s coupon rate is (perhaps significantly) lower than current “market rate” i.e. coupon rate of a bond trading at par, such as new issues.

“market rate” might also mean the spot interest rate or prevailing discount factor (i.e. yield) for the same credit quality?

Now, the same bond could appreciate in price in a few years, if market sentiment changes (yield curve drops), and this bond’s coupon rate suddenly looks attractive.