· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
Gnu Pth

GNU Pth - The GNU Portable Threads

GNU Pth - The GNU Portable Threads

Ralf S. Engelschall

¿ÕÅ°æ

¹ø¿ª
0.12003-12-29
bugiii
¿µ¹® ¿øº»À» Çѱ۷ΠÃÖÃÊ ¹ø¿ª. 1,2,3,4,6Àå ¹ø¿ª ¿Ï·á
고친 과정

Pth´Â ÀüÅëÀûÀÎ process ±â¹Ý ¼­¹öÀÇ ´ÜÁ¡À» ±Øº¹ÇÏ°í ÀÏ¹Ý ¾²·¹µå ±â¹ýÀÇ ÀåÁ¡À» ÃëÇؼ­ À̺¥Æ®·Î ±¸µ¿µÇ´Â ¾îÇø®ÄÉÀ̼ǿ¡¼­ ¿ä±¸µÇ´Â ÀÔÃâ·Â ´ÙÁßÈ­¸¦ µ¿±âÈ­ÀÇ ¾î·Á¿ò¾øÀÌ ÀÏ·ÃÀÇ È帧À¸·Î ½±°Ô ÇÁ·Î±×·¡¹ÖÇÏ°Ô ÇØÁÖ´Â ¾²·¹µå ¶óÀ̺귯¸®ÀÔ´Ï´Ù.


1. À̸§

pth - GNU Portable Threads


2. ¹öÀü

GNU Pth 2.0.0 (17-Feb-2003)


3. ¿ä¾à

Àüü ¶óÀ̺귯¸® °ü¸®(Global Library Management).

pth_init, pth_kill, pth_ctrl, pth_version.

¾²·¹µå ¼Ó¼º ó¸®(Thread Attribute Handling).

pth_attr_of, pth_attr_new, pth_attr_init, pth_attr_set, pth_attr_get, pth_attr_destroy.

¾²·¹µå Á¦¾î(Thread Control).

pth_spawn, pth_once, pth_self, pth_suspend, pth_resume, pth_yield, pth_nap, pth_wait, pth_cancel, pth_abort, pth_raise, pth_join, pth_exit.

À¯Æ¿¸®Æ¼(Utilities).

pth_fdmode, pth_time, pth_timeout, pth_sfiodisc.

Ãë¼Ò °ü¸®(Cancellation Management).

pth_cancel_point, pth_cancel_state.

À̺¥Æ® ó¸®(Event Handling).

pth_event, pth_event_typeof, pth_event_extract, pth_event_concat, pth_event_isolate, pth_event_walk, pth_event_status, pth_event_free.

Å°-±â¹Ý ÀúÀå(Key-Based Storage).

pth_key_create, pth_key_delete, pth_key_setdata, pth_key_getdata.

¸Þ½ÃÁö Æ÷Æ® Åë½Å(Message Port Communication).

pth_msgport_create, pth_msgport_destroy, pth_msgport_find, pth_msgport_pending, pth_msgport_put, pth_msgport_get, pth_msgport_reply.

¾²·¹µå û¼Ò(Thread Cleanups).

pth_cleanup_push, pth_cleanup_pop.

ÇÁ·Î¼¼½º Æ÷Å·(Process Forking).

pth_atfork_push, pth_atfork_pop, pth_fork.

µ¿±âÈ­(Synchronization).

pth_mutex_init, pth_mutex_acquire, pth_mutex_release, pth_rwlock_init, pth_rwlock_acquire, pth_rwlock_release, pth_cond_init, pth_cond_await, pth_cond_notify, pth_barrier_init, pth_barrier_reach.

»ç¿ëÀÚ-°ø°£ ÄÁÅؽºÆ®(User-Space Context).

pth_uctx_create, pth_uctx_make, pth_uctx_save, pth_uctx_restore, pth_uctx_switch, pth_uctx_destroy.

ÀϹÝÈ­µÈ POSIX ´ëü API(Generalized POSIX Replacement API).

pth_sigwait_ev, pth_accept_ev, pth_connect_ev, pth_select_ev, pth_poll_ev, pth_read_ev, pth_readv_ev, pth_write_ev, pth_writev_ev, pth_recv_ev, pth_recvfrom_ev, pth_send_ev, pth_sendto_ev.

Ç¥ÁØ POSIX ´ëü API(Standard POSIX Replacement API).

pth_nanosleep, pth_usleep, pth_sleep, pth_waitpid, pth_system, pth_sigmask, pth_sigwait, pth_accept, pth_connect, pth_select, pth_pselect, pth_poll, pth_read, pth_readv, pth_write, pth_writev, pth_pread, pth_pwrite, pth_recv, pth_recvfrom, pth_send, pth_sendto.


4. ¼³¸í

  ____  _   _
 |  _ \| |_| |__
 | |_) | __| '_ \         ``Only those who attempt
 |  __/| |_| | | |          the absurd can achieve
 |_|    \__|_| |_|          the impossible.''
 		

Pth´Â À̺¥Æ®·Î ±¸µ¿µÇ´Â(event-driven) ¾îÇø®ÄÉÀ̼ǿ¡ ¸ÖƼ¾²·¹µå¸¦ ºñ¼±Á¡Çü(non-preemtive) ¿ì¼±¼øÀ§ ±âÁØÀ¸·Î(priority-based) ½ºÄÉÁ층À» Á¦°øÇÏ´Â À̽ļºÀÌ ¸Å¿ì ³ôÀº POSIX/ANSI-C ±â¹ÝÀÇ Unix Ç÷§Æû¿ë ¶óÀ̺귯¸®ÀÔ´Ï´Ù. ¸ðµç ¾²·¹µå´Â ¾îÇø®ÄÉÀÌ¼Ç ÇÁ·Î¼¼½ºÀÇ µ¿ÀÏÇÑ ÁÖ¼Ò °ø°£¿¡¼­ ½ÇÇàµÇÁö¸¸, °¢ ¾²·¹µå´Â ÀÚ½ÅÀÇ µ¶¸³µÈ ÇÁ·Î±×·¥ Ä«¿îÅÍ, ·±Å¸ÀÓ ½ºÅÃ, ½Ã±×³Î ¸¶½ºÅ©¿Í errno º¯¼ö¸¦ °¡Áý´Ï´Ù.

n message ports, thread and process termination, and even results of customized callback functions.?> PthÀÇ ¾²·¹µå ½ºÄÉÁ층Àº »óÈ£Çù·ÂÀûÀÎ(cooperative) ¹æ¹ýÀ¸·Î µ¿ÀÛÇϴµ¥, ¿ì¼±¼øÀ§¿Í À̺¥Æ®·Î ±¸µ¿µÇ´Â ºñ¼±Á¡Çü ½ºÄÉÁì·¯¿¡ ÀÇÇؼ­ °ü¸®µÇ°í ó¸®(dispatched)µË´Ï´Ù. PthÀÇ ¸ñÇ¥´Â ¼±Á¡Çü ½ºÄÉÁ층º¸´Ù ´õ ³ªÀº À̽ļº°ú ·±Å¸ÀÓ ¼º´ÉÀ» ¾ò´Â °ÍÀÔ´Ï´Ù. ¾²·¹µå´Â À̺¥Æ® ±â´É(facility)À» ÀÌ¿ëÇؼ­ ÆÄÀÏ µð½ºÅ©¸³ÅÍ»óÀÇ º¸·ùµÈ(pending) I/O, ºñµ¿±â ½Ã±×³Î, ½Ã°£ ¸¸·á ŸÀ̸Ó(elapsed timers), ¸Þ½ÃÁö Æ÷Æ®»óÀÇ º¸·ùµÈ I/O, ¾²·¹µå¿Í ÇÁ·Î¼¼½ºÀÇ Á¾·á, ±×¸®°í »ç¿ëÀÚ Á¤ÀÇ Äݹé ÇÔ¼öÀÇ °á°ú °°Àº ´Ù¾çÇÑ ÇüÅÂÀÇ ³»ºÎ¿Í ¿ÜºÎÀûÀÎ À̺¥Æ®°¡ ¹ß»ýÇÒ ¶§±îÁö ´ë±âÇÒ ¼ö ÀÖ½À´Ï´Ù.

Pth´Â ¶ÇÇÑ ±âÁ¸ÀÇ ¸ÖƼ¾²·¹µå ¾îÇø®ÄÉÀ̼ÇÀÇ ÇÏÀ§ ȣȯ¼º¿¡ »ç¿ëÇÒ ¼ö ÀÖµµ·Ï Ãß°¡ÀûÀÎ POSIX.1c ¾²·¹µå(Pthread) ¿¡¹Ä·¹ÀÌ¼Ç API¸¦ Á¦°øÇÕ´Ï´Ù. ÀÚ¼¼ÇÑ °ÍÀº pthread(3) ¸Þ´º¾ó ÆäÀÌÁö¸¦ Âü°íÇϽʽÿÀ.


4.1. ¾²·¹µù ±âÃÊ Áö½Ä

hese processes usually do not share a common address space. Instead they are clearly separated from each other, and are created by direct cloning a process address space (although modern kernels use memory segment mapping and copy-on-write semantics to avoid unnecessary copying of physical memory).?> À̺¥Æ®·Î ±¸µ¿µÇ´Â ¾îÇø®ÄÉÀ̼Ç(´ëºÎºÐ ¼­¹öµé)À» ÇÁ·Î±×·¡¹ÖÇÒ ¶§, ¸¹Àº ÀÏ»óÀûÀÎ ÀÛ¾÷(regular jobs)°ú 1ȸ¼ºÀÇ ¿äû(one-shot requests)À» º´·ÄÀûÀ¸·Î(in parallel) ó¸®ÇØ¾ß ÇÕ´Ï´Ù. ÀÌ º´·Ä 󸮸¦ ´ÜÀÏ ÇÁ·Î¼¼¼­(uniprocessor) ¸Ó½Å¿¡¼­ È¿°úÀûÀ¸·Î Èä³»³»±â(simulate) À§Çؼ­, ¸ÖƼŽºÅ·À» »ç¿ëÇϴµ¥, ¾îÇø®ÄÉÀ̼ÇÀº ÀÚ½ÅÀÇ ´ÙÁß ÀνºÅϽº¸¦ ½ºÆùÇϵµ·Ï ¿î¿µÃ¼Á¦¿¡°Ô ¿äûÇÕ´Ï´Ù. Unix»ó¿¡¼­ Ä¿³ÎÀº ÀüÇüÀûÀ¸·Î ¹«°Å¿î(heavy-weight) fork(2)·Î ½ºÆùµÇ´Â ÇÁ·Î¼¼½º¸¦ ÅëÇؼ­ ¼±Á¡ÇüÀÌ°í ¿ì¼±¼øÀ§ ±â¹ÝÀÇ ¸ÖƼŽºÅ·À» ±¸ÇöÇÕ´Ï´Ù. ´ë°³ À̵é ÇÁ·Î¼¼½ºµéÀº ÀϹÝÀûÀÎ ÁÖ¼Ò °ø°£À» °øÀ¯ÇÏÁö ¾Ê½À´Ï´Ù. ´ë½Å ÇÁ·Î¼¼½ºµéÀº ¿ÏÀüÈ÷ ´Ù¸¥ ÇÁ·Î¼¼½ºµé°ú ºÐ¸®µÇ¸ç, ÇÁ·Î¼¼½º ÁÖ¼Ò °ø°£À» Á÷Á¢ Ŭ·ÐÇؼ­ »ý¼ºÇÕ´Ï´Ù. (¹°·Ð Çö´ëÀûÀÎ Ä¿³ÎÀº ¸Þ¸ð¸® ¼¼±×¸ÕÆ® ¸ÅÇΰú ¾²±â½Ã º¹»ç ±â¹ý(copy-on-write semantics)À¸·Î ºÒÇÊ¿äÇÑ ¹°¸®Àû ¸Þ¸ð¸®ÀÇ º¹»ç¸¦ ÇÇÇÕ´Ï´Ù.)

request spawns a sub-process to handle it, the server performance and responsiveness is horrible (heavy-weight processes cost time to spawn). Finally, the server application doesn't scale very well with the load because of these resource problems. In practice, lots of tricks are usually used to overcome these problems - ranging from pre-forked sub-process pools to semi-serialized processing, etc.?> ÀÌ°ÍÀÇ ´ÜÁ¡Àº ¸í¹éÇÕ´Ï´Ù. ÇÁ·Î¼¼½º°£¿¡ µ¥ÀÌÅ͸¦ °øÀ¯ÇÏ´Â °ÍÀÌ º¹ÀâÇÏ°í, ´ë°³ °øÀ¯ ¸Þ¸ð¸®¸¦ ÅëÇؼ­¸¸ È¿À²ÀûÀ¸·Î ¼öÇàµË´Ï´Ù. (ÇÏÁö¸¸, °øÀ¯ ¸Þ¸ð¸®´Â À̽ļºÀÌ ¸¹ÀÌ ºÎÁ·ÇÕ´Ï´Ù.) ÇÁ·Î¼¼½º°£ µ¿±âÈ­(synchronization)µµ Unix ½ºÄÉÁì·¯ÀÇ ¼±Á¡Çü Ư¼º ¶§¹®¿¡ ó¸®ÇϱⰡ ±î´Ù·Ó½À´Ï´Ù. (¿øÀÚÀû Àá±Ý(atomic locks)À» »ç¿ëÇØ¾ß ÇÕ´Ï´Ù.) ¼­¹ö ¾îÇø®ÄÉÀ̼ÇÀº ¾ÆÁÖ ¸¹°í ±ä ½ÇÇà ¿äûÀ» (¹«°Å¿î ÇÁ·Î¼¼½º´Â ¸Þ¸ð¸®¸¦ ¼Òºñ ÇÕ´Ï´Ù.) ó¸®ÇØ¾ß ÇÒ ¶§, ±â°èÀÇ ÀÚ¿øÀ» ¾ÆÁÖ ºü¸£°Ô ¼Ò¸ðÇÒ ¼ö ÀÖ½À´Ï´Ù. ¸¶Áö¸·À¸·Î, ¼­¹ö ¾îÇø®ÄÉÀ̼ÇÀº ÀÌ·± ÀÚ¿ø ¹®Á¦ ¶§¹®¿¡ ºÎÇÏ¿¡ ´ëÇؼ­ Àß ´ëóÇÒ(scale) ¼ö ¾ø½À´Ï´Ù. ½ÇÁ¦·Î ÀÌ·± ¹®Á¦¸¦ ±Øº¹Çϱâ À§Çؼ­ ¹Ì¸® Æ÷Å©µÈ ¼­ºê ÇÁ·Î¼¼½º Ç®À̳ª semi-serialized processing µî°ú °°Àº ±â¹ýµéÀÌ »ç¿ëµË´Ï´Ù.

pes of applications, nor can all applications benefit from them. But at least event-driven server applications usually benefit greatly from using threads.?> ÀÌ·± ÀÚ¿ø°ú µ¥ÀÌÅÍ °øÀ¯ ¹®Á¦¸¦ ÇØ°áÇÒ ¼ö ÀÖ´Â °¡Àå ¼¼·ÃµÈ ¹æ¹ý Áß¿¡ Çϳª´Â ÇϳªÀÇ (¹«°Å¿î) ÇÁ·Î¼¼¼­ ¾È¿¡¼­ ¸ÖƼ¾²·¹µùÀ» »ç¿ëÇÏ´Â ¿©·¯ °³ÀÇ °¡º­¿î ½ÇÇà ¾²·¹µå¸¦ °¡Áö´Â °ÍÀÔ´Ï´Ù. ÀÌµé ¾²·¹µåµéÀº ´ë°³ ¾îÇø®ÄÉÀ̼ÇÀÇ ÀÀ´ä¼º(responsiveness)°ú ¼º´ÉÀ» Çâ»ó½ÃÅ°°í, Á¾Á¾ ³»ºÎÀûÀÎ ÇÁ·Î±×·¥ ±¸Á¶¸¦ Çâ»ó½ÃÅ°°í ´Ü¼øÈ­ ½ÃÅ°¸ç, ƯÈ÷ ¹«°Å¿î ÇÁ·Î¼¼½ºº¸´Ù ½Ã½ºÅÛ ÀÚ¿øÀ» ´ú ¿ä±¸ÇÕ´Ï´Ù. ¾²·¹µå´Â ¸ðµç ÇüÅÂÀÇ ¾îÇø®ÄÉÀ̼ǿ¡ ÃÖÀûÈ­µÈ ·±Å¸ÀÓ ¼³ºñ(facility)´Â ¾Æ´Ï¸ç, ¸ðµç ¾îÇø®ÄÉÀ̼ÇÀÌ À̵æÀ» º¼ ¼ö ÀÖ´Â °Íµµ ¾Æ´Õ´Ï´Ù. ±×·¸Áö¸¸ ÃÖ¼ÒÇÑ À̺¥Æ®·Î ±¸µ¿µÇ´Â ¼­¹ö ¾îÇø®ÄÉÀ̼ǿ¡¼­´Â ÀϹÝÀûÀ¸·Î ¾²·¹µå¸¦ »ç¿ëÇϸé Å©°Ô À̵æÀ» º¼ ¼ö ÀÖ½À´Ï´Ù.


4.2. ¾²·¹µùÀÇ ¼¼°è

¾²·¹µùÀÇ ¼¼°è¸¦ ¼³¸íÇÏ°í Á¤ÀÇÇÏ´Â ¹®¼­µéÀº ¾ÆÁÖ ¸¹Áö¸¸, Pth¸¦ ÀÌÇØÇϱâ À§Çؼ­, ¾²·¹µù¿¡ ´ëÇÑ ±âº»ÀûÀÎ Áö½ÄÀÌ ÇÊ¿äÇÕ´Ï´Ù. ÃÖ¼ÒÇÑ ´ÙÀ½ÀÇ ¾²·¹µå¿¡ °ü·ÃµÈ ¿ë¾îÀÇ Á¤ÀÇ´Â ¾²·¹µå ÇÁ·Î±×·¡¹ÖÀ» ÀÌÇØÇÏ´Â µ¥ µµ¿òÀ» ÁÙ °ÍÀÌ°í Pth¸¦ »ç¿ëÇÏ´Â µ¥ ÃæºÐÇÒ °ÍÀÔ´Ï´Ù.

  • ÇÁ·Î¼¼½º vs. ¾²·¹µå

    ual memory, it shares with the other threads of the same process. ?> Unix ½Ã½ºÅÛ»óÀÇ ÇÁ·Î¼¼½º´Â ÃÖ¼ÒÇÑ ´ÙÀ½°ú °°Àº ±âº»ÀûÀÎ ¿ä¼Ò·Î ±¸¼ºµË´Ï´Ù: °¡»ó ¸Þ¸ð¸® Å×À̺í, ÇÁ·Î±×·¥ ÄÚµå, ÇÁ·Î±×·¥ Ä«¿îÅÍ, Èü ¸Þ¸ð¸®, ½ºÅà ¸Þ¸ð¸®, ½ºÅà Æ÷ÀÎÅÍ, ÆÄÀÏ µð½ºÅ©¸³ÅÍ ¼¼Æ®, ½Ã½º³Î Å×À̺í. ÇÁ·Î¼¼½º ÀüȯÀÌ ÀÏ¾î ³¯ ¶§¸¶´Ù, Ä¿³ÎÀº ÀÌµé ¿ä¼Ò¸¦ µ¶¸³µÈ ÇÁ·Î¼¼½ºµéÀ» À§Çؼ­ ÀúÀåÇÏ°í º¹±¸ÇÕ´Ï´Ù. ÇÑÆí, ¾²·¹µå´Â ´ÜÁö ÀڽŸ¸ÀÇ ÇÁ·Î±×·¥ Ä«¿îÅÍ, ½ºÅà ¸Þ¸ð¸®, ½ºÅà Æ÷ÀÎÅÍ¿Í ½ÅÈ£ Å×À̺í·Î ±¸¼ºµË´Ï´Ù. ¸ðµç ´Ù¸¥ ¿ä¼Ò´Â (ƯÈ÷ °¡»ó ¸Þ¸ð¸®) °°Àº ÇÁ·Î¼¼½ºÀÇ ´Ù¸¥ ½º·¹µåµé°ú °øÀ¯ÇÏ°Ô µË´Ï´Ù.

  • Ä¿³Î-°ø°£(kernel-space) vs. »ç¿ëÀÚ-°ø°£(user-space) ¾²·¹µù

    one or more user-space threads to one or more kernel-space threads (there usually called light-weight processes - or in short LWPs). ?> Unix Ç÷§Æû»óÀÇ ¾²·¹µåµéÀº ÀüÅëÀûÀ¸·Î Ä¿³Î-°ø°£ ¶Ç´Â »ç¿ëÀÚ-°ø°£¿¡¼­ ±¸ÇöµÉ ¼ö ÀÖ½À´Ï´Ù. ¾²·¹µå°¡ Ä¿³Î¿¡ ÀÇÇؼ­ ±¸ÇöµÉ ¶§, ¾²·¹µå ÄÁÅؽºÆ® ÀüȯÀº ¾îÇø®ÄÉÀ̼ǰú »ó°ü¾øÀÌ Ä¿³Î¿¡ ÀÇÇؼ­ ¼öÇàµË´Ï´Ù. ºñ½ÁÇÏ°Ô ¾²·¹µå°¡ »ç¿ëÀÚ °ø°£¿¡¼­ ±¸ÇöµÉ ¶§, ¾²·¹µå ÄÁÅؽºÆ® ÀüȯÀº Ä¿³Î°ú »ó°ü¾øÀÌ ¾îÇø®ÄÉÀÌ¼Ç ¶óÀ̺귯¸®¿¡ ÀÇÇؼ­ ¼öÇàµË´Ï´Ù. ¶ÇÇÑ ÇÏÀ̺긮µå ¾²·¹µù Á¢±Ù¹ýµµ Àִµ¥, ÀÌ°ÍÀº ÀüÇüÀûÀ¸·Î »ç¿ëÀÚ-°ø°£ ¶óÀ̺귯¸®°¡ Çϳª ÀÌ»óÀÇ »ç¿ëÀÚ-°ø°£ ¾²·¹µå¸¦ Çϳª ÀÌ»óÀÇ Ä¿³Î-°ø°£ ¾²·¹µå¿Í °áÇÕ½Ãŵ´Ï´Ù. (À̵éÀ» ´ë°³ °¡º­¿î(light-weight) ÇÁ·Î¼¼½º, ÁÙ¿©¼­ LWP ¶ó°í ºÎ¸¨´Ï´Ù.)

    or non-preemptive scheduling.?> »ç¿ëÀÚ °ø°£ ¾²·¹µå´Â ´ë°³ Á» ´õ À̽ļºÀÌ ÀÖÀ¸¸ç ÄÁÅؽºÆ® ÀüȯÀ» Á» ´õ ºü¸£°í ¼Õ½±°Ô ¼öÇàÇÒ ¼ö ÀÖ½À´Ï´Ù. ÇÑÆí, Ä¿³Î °ø°£ ¾²·¹µå´Â ´ÙÁß ÇÁ·Î¼¼¼­(multiprocessor) ±â±âÀÇ ÀåÁ¡À» ÃëÇÒ ¼ö ÀÖ°í, ¾î¶² °íÀ¯ÀÇ I/O ºí·¯Å· ¹®Á¦¸¦ ÇÇÇÒ ¼ö ÀÖ½À´Ï´Ù. Ä¿³Î-°ø°£ ¾²·¹µå´Â ´ë°³ ±âº»ÀûÀ¸·Î ÇÁ·Î¼¼½º¿Í ¹ÐÁ¢ÇÑ °ü°è¸¦ °¡Áö°í ¼±Á¡ÇüÀ¸·Î ½ºÄÉÁì µË´Ï´Ù. ÇÑÆí »ç¿ëÀÚ-°ø°£ ¾²·¹µå´Â ¼±Á¡Çü ¶Ç´Â ºñ¼±Á¡Çü ½ºÄÉÁ층À» »ç¿ëÇÕ´Ï´Ù.

  • ¼±Á¡Çü vs. ºñ¼±Á¡Çü ¾²·¹µå ½ºÄÉÁ층

    ling, once a thread received control from the scheduler it keeps it until either a blocking situation occurs (again a function call which would block and instead switches back to the scheduler) or the thread explicitly yields control back to the scheduler in a cooperative way. ?> ¼±Á¡Çü ½ºÄÉÁ층¿¡¼­, ½ºÄÉÁì·¯´Â ¾²·¹µå°¡ ºí·¯Å· »óÅ°¡ ¹ß»ý(´ë°³ ºí·°µÇ´Â ÇÔ¼ö È£Ãâ)Çϰųª ÁöÁ¤µÈ ½Ã°£ÀÌ Áö³¯ ¶§±îÁö ½ÇÇàÇϵµ·Ï ÇÕ´Ï´Ù. ±×¸®°í ³ª¼­ ½ºÄÉÁì·¯´Â ÇÒ ÀÏÀÌ ÀÖ´Â ´Ù¸¥ ¾²·¹µå·Î Á¦¾î±ÇÀ» ³Ñ°ÜÁÝ´Ï´Ù. ÀÌ°ÍÀº ´ë°³ Çϵå¿þ¾î ÀÎÅÍ·´Æ® ½ÅÈ£(Ä¿³Î-°ø°£ ¾²·¹µåÀÏ °æ¿ì)³ª SIGALRMÀ̳ª SIGVTALRM °°Àº ¼ÒÇÁÆ®¿þ¾î ÀÎÅÍ·´Æ® ½ÅÈ£(»ç¿ëÀÚ-°ø°£ ¾²·¹µå)¸¦ ÅëÇؼ­ ¾²·¹µå¸¦ ÁßÁö½ÃÄѼ­(by interrupting) ½ÇÇöÇÕ´Ï´Ù. ºñ¼±Á¡Çü ½ºÄÉÁ층¿¡¼­, ¾²·¹µå°¡ ½ºÄÉÁì·¯¿¡¼­ Á¦¾î±ÇÀ» ³Ñ°Ü¹ÞÀ¸¸é, ºí·¯Å· »óȲÀÌ ¹ß»ý(ºí·°µÇ´Â ÇÔ¼ö È£ÃâÀº ½ºÄÉÁì·¯·Î Àüȯ)Çϰųª ¾²·¹µå°¡ (»óÈ£Çù·ÂÀûÀÎ ¹æ¹ýÀÎ) ¸í½ÃÀûÀ¸·Î ½ºÄÉÁì·¯¿¡°Ô Á¦¾î±ÇÀ» ³Ñ±æ ¶§±îÁö ½ÇÇàµË´Ï´Ù.

  • º´Ç༺(concurrency) vs. º´·Ä¼º(parallelism)

    º´Ç༺Àº µÎ°³ ÀÌ»óÀÇ ¾²·¹µå°¡ ¶È°°Àº ½Ã°¢¿¡ ÁøÇà ÁßÀÏ ¶§(in progress) ÀϾ´Ï´Ù. º´·Ä¼ºÀº ÃÖ¼ÒÇÑ µÎ°³ ÀÌ»óÀÇ ¾²·¹µå°¡ µ¿½Ã¿¡ ½ÇÇàµÉ ¶§(executing) ÀϾ´Ï´Ù. ¹°·Ð, ÁøÁ¤ÇÑ º´·Ä¼ºÀº ´ÙÁß ÇÁ·Î¼¼¼­ ±â°è¿¡¼­¸¸ ´Þ¼ºµÉ ¼ö ÀÖ½À´Ï´Ù. ÇÏÁö¸¸ º´·Ä¼º ¶Ç´Â ³ôÀº º´Ç༺À» ¼±Á¡Çü ¾²·¹µå ½ºÄÉÁ층, ³·Àº º´Ç༺À» ºñ¼±Á¡Çü ¾²·¹µå ½ºÄÉÁ층À¸·Î ¾ð±ÞµÇ±âµµ ÇÕ´Ï´Ù.

  • ÀÀ´ä¼º(responsiveness)

    ½Ã½ºÅÛÀÇ ÀÀ´ä¼ºÀº ¿ÜºÎÀÇ ¿äû¿¡ ´ëÇØ ½Ã½ºÅÛÀÌ ÀÀ´äÇÒ ¶§±îÁö »ç¿ëÀÚ°¡ º¼ ¼ö ÀÖ´Â Áö¿¬¿¡ ÀÇÇؼ­ ¼³¸íÇÒ ¼ö ÀÖ½À´Ï´Ù. ÀÌ Áö¿¬ÀÌ ÃæºÐÈ÷ À۰ųª »ç¿ëÀÚ°¡ ¶Ñ·ÇÇÏ°Ô ÀνÄÇÏÁö ¸øÇÑ´Ù¸é, ½Ã½ºÅÛÀÇ ÀÀ´ä¼ºÀº ÁÁ´Ù°í ÇÒ ¼ö ÀÖ½À´Ï´Ù. »ç¿ëÀÚ°¡ ÀÌ Áö¿¬À» ÀνÄÇϰųª ºÒÆíÀ» ´À³¢°Ô µÇ¸é, ½Ã½ºÅÛÀÇ ÀÀ´ä¼ºÀº ³ª»Ú´Ù°í ÇÒ ¼ö ÀÖ½À´Ï´Ù.

  • ÀçÁøÀÔ(reentrant), ¾²·¹µå-¾ÈÀü(thread-safe) ±×¸®°í ºñµ¿±â-¾ÈÀü(asynchronous-safe) ÇÔ¼ö

    ÀçÁøÀÔ ÇÔ¼ö´Â ¿©·¯ ¾²·¹µåµéÀÌ ÀÌ ÇÔ¼ö¸¦ µ¿½Ã¿¡ È£ÃâÇÏ°í µ¿½Ã¿¡ ½ÇÇàµÉ ¶§ ¿Ã¹Ù¸£°Ô µ¿ÀÛÇÏ´Â ÇÔ¼öÀÔ´Ï´Ù. ¸Þ¸ð¸® ȤÀº ÆÄÀÏ °°Àº Àü¿ª »óŸ¦ ¾ï¼¼½ºÇÏ´Â ÇÔ¼ö´Â ÀçÁøÀÔÀÌ °¡´ÉÇϵµ·Ï Á¶½É½º·´°Ô ¼³°è µÇ¾î¾ß ÇÕ´Ï´Ù. ÀÌ ¹®Á¦¸¦ ÇØ°áÇÏ´Â µÎ°³ÀÇ ÀüÅëÀûÀÎ Á¢±Ù¹ýÀº È£ÃâÀÚ ÂÊ¿¡¼­ »óŸ¦ Á¦°øÇÏ´Â °Í°ú ¾²·¹µåº°(thread-specific) µ¥ÀÌÅÍÀÔ´Ï´Ù.

    th an internal mutual exclusion lock (aka `mutex'). As you should recognize, reentrant is a stronger attribute than thread-safe, because it is harder to achieve and results especially in no run-time contention between threads. So, a reentrant function is always thread-safe, but not vice versa.?> ¾²·¹µå-¾ÈÀüÀ̶ó´Â °ÍÀº ¿©·¯ °³ÀÇ ¾²·¹µå°¡ µ¥ÀÌÅ͸¦ ÀÐ°í ¾µ ¶§ (¿¹ÃøÇÒ ¼ö ¾ø´Â) ½ÇÇà ¼ø¼­¿¡ µû¶ó ºÎÁ¤È®ÇÑ °ªÀÌ µÉ ¼öµµ ÀÖ´Â, µ¥ÀÌÅÍ °æÀï(races)ÀÌ ¾ø´Ù´Â °ÍÀÔ´Ï´Ù. ¸î°³ÀÇ ¾²·¹µå°¡ µ¿½Ã¿¡ ¾î¶² ÇÔ¼ö¸¦ È£ÃâÇÏ¿´À» ¶§, ÀÌ ÇÔ¼ö°¡ ¿Ã¹Ù¸¥ ÇൿÀ» ÇÑ´Ù¸é ÀÌ ÇÔ¼ö¸¦ ¾²·¹µå-¾ÈÀüÀÔ´Ï´Ù. (ÀÌ ÇÔ¼ö°¡ ²À µ¿½Ã¿¡ ½ÇÇàµÇ¾î¾ß ÇÏ´Â °ÍÀº ¾Æ´Õ´Ï´Ù.) ¾²·¹µå-¾ÈÀüÀ» ´Þ¼ºÇÏ´Â ÀüÅëÀûÀÎ Á¢±Ù¹ýÀº ¹ÂÅؽº(mutex, mutual exclusion lock)·Î ÇÔ¼ö Àüü¸¦ °¨½Î´Â °ÍÀÔ´Ï´Ù.

    stem functions it is allowed to call). The reason mainly is, because only a few system functions are officially declared by POSIX as guaranteed to be asynchronous-safe. Asynchronous-safe functions usually have to be already reentrant.?> Ãß°¡ÀûÀ¸·Î ½Ã±×³Î Çڵ鷯¿Í °áÇÕµÇ¾î µ¿ÀÛÇÒ ¶§ µû¶ó ¿À´Â ºñµ¿±â-¾ÈÀüÀ̶ó°í ÇÏ´Â ÇÔ¼ö¿Í °ü·ÃµÈ ¼Ó¼ºÀÌ ÀÖ½À´Ï´Ù. ÀÌ°ÍÀº ÀçÁøÀÔ ÇÔ¼öÀÇ ¹®Á¦¿Í ¹ÐÁ¢ÇÑ ¿¬°üÀÌ ÀÖ½À´Ï´Ù. ºñµ¿±â-¾ÈÀü ÇÔ¼ö´Â ½Ã±×³Î Çڵ鷯 ÄÁÅؽºÆ®»ó¿¡¼­ ¾ÈÀüÇÏ°í ºÎÀÛ¿ë¾øÀÌ È£ÃâµÉ ¼ö ÀÖ´Â ÇÔ¼öÀÔ´Ï´Ù. ¾îÇø®ÄÉÀ̼ÇÀº ½Ã±×³Î Çڵ鷯¿¡¼­ ÀÛ¾÷À» ¾ÆÁÖ Á¦ÇÑÀûÀ¸·Î (ƯÈ÷ »ç¿ëÇÒ ¼ö ÀÖ´Â ½Ã½ºÅÛ ÇÔ¼öÀÇ Á¦ÇÑ) ¼öÇàÇØ¾ß ÇϹǷÎ, ÀÌ·± ÇüÅÂÀÇ ÇÔ¼ö´Â ±×¸® ¸¹Áö ¾Ê½À´Ï´Ù. ÁÖ¿ä ¿øÀÎÀº ¼Ò¼öÀÇ ½Ã½ºÅÛ ÇÔ¼ö¸¸ÀÌ ºñµ¿±â-¾ÈÀüÀ» º¸ÀåÇÑ´Ù°í POSIX¿¡ ÀÇÇØ °ø½ÄÀûÀ¸·Î ¼±¾ðµÇ¾î Àֱ⠶§¹®ÀÔ´Ï´Ù. ºñµ¿±â-¾ÈÀü ÇÔ¼ö´Â ´ëºÎºÐ ÀçÁøÀÔ ÇÔ¼öÀ̱⵵ ÇÕ´Ï´Ù.


4.3. »ç¿ëÀÚ-°ø°£ ¾²·¹µå

»ç¿ëÀÚ-°ø°£ ¾²·¹µå´Â ´Ù¾çÇÑ ¹æ¹ýÀ¸·Î ±¸ÇöÇÒ ¼ö ÀÖ½À´Ï´Ù. ÀüÅëÀûÀÎ µÎ°¡Áö ¹æ¹ýÀº ´ÙÀ½°ú °°½À´Ï´Ù.

  1. ¸ÅÆ®¸¯½º ±â¹ÝÀÇ ¸í½ÃÀûÀÎ ÀÛÀº ½ÇÇà À¯´ÏÆ® °£ ó¸®(Matrix-based explicit dispatching between small units of execution):

    ore than one jump-trail through this matrix and by switching between these jump-trails controlled by corresponding occurred events.?> ¾îÇø®ÄÉÀ̼ÇÀÇ Àüü ÇÁ·Î½ÃÁ®µéÀ» ÀÛÀº ½ÇÇà À¯´ÏÆ®·Î Àß°Ô ³ª´©°í (¸î ¹Ð¸®ÃÊÀÌ»ó ½ÇÇàµÇÁö ¾Êµµ·Ï) À̵é À¯´ÏÆ®¸¦ ºÐ¸®µÈ ÇÔ¼ö·Î ±¸ÇöÇÕ´Ï´Ù. ±× ´ÙÀ½ À̵é ÇÔ¼öÀÇ ½ÇÇà (¶ÇÇÑ ÀÇÁ¸ »óÅÂ) ¼ø¼­¸¦ ¼³¸íÇÏ´Â Àüü ¸ÅÆ®¸¯½º¸¦ Á¤ÀÇÇÕ´Ï´Ù. ¸ÞÀÎ ¼­¹ö ÇÁ·Î½ÃÁ®´Â ÀÌ ¸ÅÆ®¸¯½º¿¡ ÀÇÇؼ­ Á¦¾îµÇ´Â °¢±â ´Ù¸¥ ÇÔ¼öµé¿¡ µû¶ó ÇÑ ÇÔ¼ö¸¦ È£ÃâÇؼ­ À̵é À¯´ÏÆ®µé°£ÀÇ Ã³¸®(dispatch)¸¦ ¼öÇàÇÕ´Ï´Ù. ÀÌ ¸ÅÆ®¸¯½º¸¦ ÅëÇÑ Çϳª ÀÌ»óÀÇ jump-trail°ú ¹ß»ýµÈ À̺¥Æ®¿Í ´ëÀÀµÇ¾î Á¦¾îµÇ´Â À̵é jump-trails °£ÀÇ Àüȯ¿¡ ÀÇÇؼ­ ¾²·¹µå°¡ »ý¼ºµË´Ï´Ù.

    ÀÌ Á¢±Ù¹ýÀº ¸ÅÆ®¸¯½º¸¦ Á¶ÀýÇÔÀ¸·Î½á ½ÇÇà ¾²·¹µå¸¦ ÃÖÀûÈ­ ÇÒ ¼ö ÀÖ°í, ¾îÇø®ÄÉÀÌ¼Ç ÀÚü°¡ ¸í½ÃÀûÀ¸·Î ½ºÄÉÁ층Çϱ⠶§¹®¿¡ ³ôÀº ¼º´ÉÀ» ³¾ ¼ö ÀÖ½À´Ï´Ù. ¶ÇÇÑ ¸ÅÆ®¸¯½º´Â ÀϹÝÀûÀÎ µ¥ÀÌÅÍ ±¸Á¶ÀÌ°í, ÇÔ¼ö´Â ANSI CÀÇ Ç¥ÁØ Æ¯Â¡À̱⠶§¹®¿¡ À̽ļºÀÌ ¸Å¿ì ³ô½À´Ï´Ù.

    ften nasty, because one cannot switch between threads in the middle of a function. Thus the scheduling borders are the function borders.?> ÀÌ Á¢±Ù¹ýÀÇ ´ÜÁ¡Àº ÀÌ ¹æ¹ýÀ¸·Î Å« ¾îÇø®ÄÉÀ̼ÇÀ» ÀÛ¼ºÇÏ¸é ½ÇÇà À¯´ÏÆ®°¡ ½±°Ô ¼ö¹é°³¸¦ ³Ñ¾î°¡±â ¶§¹®¿¡ Å« ¾îÇø®ÄÉÀ̼ÇÀ» ÀÛ¼ºÇÏ´Â °ÍÀÌ º¹ÀâÇØÁö°í, (ÇÔ¼ö ´ÜÀ§·Î ÀÛ¾÷ÀÌ ÀüȯµÇ°í ´ÙÀ½Àº ¹«¾ùÀÎÁö Ç×»ó Àü¿ª ó¸® ¸ÅÆ®¸¯½º¸¦ ±â¾ïÇØ¾ß Çϱ⠶§¹®¿¡) ¾îÇø®ÄÉÀÌ¼Ç ³»ºÎÀÇ Á¦¾î È帧À» ÀÌÇØÇϱ⠸ſì Èûµì´Ï´Ù. Ãß°¡ÀûÀ¸·Î, ¸ðµç ½º·¹µå´Â ¶È°°Àº ½ÇÇà ½ºÅû󿡼­ µ¿ÀÛÇؼ­ ¸Þ¸ð¸®¸¦ Àý¾àÇϱâ´Â ÇÏÁö¸¸, ½ºÄÉÁ층 ´ÜÀ§°¡ ÇÔ¼ö ´ÜÀ§À̱⠶§¹®¿¡, ÇÔ¼ö Áß°£¿¡¼­ ¾²·¹µå°£ ÀüȯÀÌ ºÒ°¡´ÉÇÕ´Ï´Ù. ÀÌ ¶§¹®¿¡ ³­Ã³ÇÑ °æ¿ì°¡ ÀÖ½À´Ï´Ù.

  2. ÄÁÅؽºÆ® ±â¹ÝÀÇ ¾Ï½ÃÀûÀÎ ½ÇÇà ¾²·¹µå°£ ½ºÄÉÁ층(Context-based implicit scheduling between threads of execution):

    tself doesn't recognize this and usually (except for synchronization issues) doesn't have to care about this.?> ÀÌ ¾ÆÀ̵ð¾î´Â Æ÷Å©µÈ ÇÁ·Î¼¼½ºÃ³·³ ¾îÇø®ÄÉÀ̼ÇÀ» ÇÁ·Î±×·¥ÇÏ´Â °ÍÀÔ´Ï´Ù. Áï, ½ÇÇà ¾²·¹µå¸¦ ½ºÆùÇϸé Á¦¾î È帧ÀÇ °¡·Îä±â ¾øÀÌ Ã³À½ºÎÅÍ ³¡±îÁö ½ÇÇàµÇ´Â °ÍÀÔ´Ï´Ù. ÇÏÁö¸¸ Á¦¾î È帧Àº ÇÔ¼ö Áß°£¿¡¼­µµ °¡·Îä±â ´çÇÒ ¼ö ÀÖ½À´Ï´Ù. ½ÇÁ¦·Î ¼±Á¡Çü ¹æ¹ýÀ¸·Î, Ä¿³ÎÀÌ ¹«°Å¿î ÇÁ·Î¼¼½º¿¡°Ô ÇÏ´Â °Í°ú ºñ½ÁÇÏ°Ô, ¸Å ¸î ¹Ð¸®Ãʸ¶´Ù »ç¿ëÀÚ-°ø°£ ½ºÄÉÁì·¯´Â ½ÇÇà ¾²·¹µå°£ ÀüȯÀ» ÇÕ´Ï´Ù. ÇÏÁö¸¸ ¾²·¹µå ÀÚü´Â ÀÌ°ÍÀ» ÀνÄÇÏÁö ¾ÊÀ¸¸ç (µ¿±âÈ­ ¹®Á¦¸¦ Á¦¿ÜÇÏ°í) ´ëºÎºÐ ÀÌ°Í¿¡ ´ëÇؼ­ »ý°¢ÇÒ ÇÊ¿ä°¡ ¾ø½À´Ï´Ù.

    ÀÌ Á¢±Ù¹ýÀÇ ÀåÁ¡Àº ¾²·¹µåÀÇ Á¦¾î È帧°ú ÄÁÅؽºÆ®´Â ÇÔ¼ö ´ÜÀ§ÀÇ °­Á¦ÀûÀÎ °¡·Îä±â ¾øÀÌ ¸í·ÉÀ» ¼øÂ÷ÀûÀ¸·Î ½ÇÇàÇϱ⠶§¹®¿¡, ÇÁ·Î±×·¥ÇÏ±â ¸Å¿ì ½±´Ù´Â °ÍÀÔ´Ï´Ù. Ãß°¡ÀûÀ¸·Î, ÇÁ·Î±×·¡¹ÖÀº ÀüÅëÀûÀÌ°í Àß ÀÌÇصǴ fork(2) ±â¹Ý Á¢±Ù¹ý°ú ¸Å¿ì À¯»çÇÕ´Ï´Ù.

    ble POSIX/ANSI-C based way to implement user-space preemptive threading. Either the platform already has threads, or one has to hope that some semi-portable package exists for it. And even those semi-portable packages usually have to deal with assembler code and other nasty internals and are not easy to port to forthcoming platforms.?> ´ÜÁ¡Àº ºñ·Ï ¹«°Å¿î ÇÁ·Î¼¼½º ±â¹ÝÀÇ Á¢±Ù¹ýÀ» »ç¿ëÇÏ´Â °Í°ú ºñ±³Çؼ­ ÀϹÝÀûÀÎ ¼º´ÉÀº Çâ»óµÇÁö¸¸, ¸ÅÆ®¸¯½º Á¢±Ù¹ýº¸´Ù´Â ¼º´ÉÀÌ ¶³¾îÁø´Ù´Â °ÍÀÔ´Ï´Ù. ÀÌ°ÍÀº ¾Ï½ÃÀûÀÎ ¼±Á¡Çü ½ºÄÉÁ층Àº ´ë°³ ¸í½ÃÀûÀÎ »óÈ£Çù·ÂÀûÀÎ/ºñ¼±Á¡Çü ½ºÄÉÁ층º¸´Ù ´õ ¸¹Àº ÄÁÅؽºÆ® ÀüȯÀ» Çϱ⠶§¹®ÀÔ´Ï´Ù. (»ç¿ëÀÚ-°ø°£ ÄÁÅؽºÆ® ÀüȯÀº Ä¿³Î-°ø°£ ÄÁÅؽºÆ® ÀüÈ­º¸´Ù´Â ¿À¹öÇìµå°¡ Àû½À´Ï´Ù.) ¸¶Áö¸·À¸·Î, »ç¿ëÀÚ-°ø°£ÀÇ ¼±Á¡Çü ¾²·¹µùÀ» ±¸ÇöÇϱâ À§ÇÑ POSIX/ANSI-C ±â¹ÝÀÇ À̽ļº ÀÖ´Â ¹æ¹ýÀÌ ¾ø´Ù´Â °ÍÀÔ´Ï´Ù. Ç÷§ÆûÀÌ ÀÌ¹Ì ¾²·¹µå¸¦ Áö¿ø°Å³ª ¾î¶² ¾à°£ À̽ļº ÀÖ´Â ÆÐÅ°Áö°¡ ÀÖ´Ù°í ÇÏ´õ¶óµµ À̵é ÆÐÅ°Áö´Â ´ë°³ ¾î¼Àºí·¯ ÄÚµå¿Í º¹ÀâÇÑ ³»ºÎ»çÇ×À» ó¸®ÇØ¾ß ÇÏ°í »õ·Î ³ª¿À´Â Ç÷§Æû¿¡ À̽ÄÇϱ⵵ ½±Áö ¾Ê½À´Ï´Ù.

    ¿ä¾àÇϸé: ¸ÅÆ®¸¯½º-ó¸® Á¢±Ù¹ýÀº À̽ļºÀÌ ÀÖ°í ºü¸£Áö¸¸, ÇÁ·Î±×·¥Çϱâ´Â ¾î·Æ½À´Ï´Ù. ¾²·¹µå ½ºÄÉÁ층 Á¢±Ù¹ýÀº ÇÁ·Î±×·¥Çϱ⠽±Áö¸¸, ¼±Á¡Çü Ư¼º ¶§¹®¿¡ µ¿±âÈ­¿Í À̽ļº ¹®Á¦·Î °ñÄ¡°¡ ¾ÆÇÅ´Ï´Ù.


4.4. PthÀÇ ÀýÃæ¾È

±×·¯¸é ¿Ö ÀÌµé ´ÜÁ¡À» ÇÇÇϱâ À§Çؼ­ ¾çÁ· Á¢±Ù¹ýÀÇ ÀåÁ¡À» °áÇÕÇÏÁö ¾Ê´Â °ÍÀϱî¿ä? ÀÌ°ÍÀÌ ¹Ù·Î PthÀÇ ¸ñÇ¥ÀÔ´Ï´Ù. Pth´Â ¾²·¹µå ÇÁ·Î±×·¡¹ÖÀ» ½±°Ô ÇØÁָ鼭, ºñ¼±Á¡Çü ½ºÄÉÁ층À» »ç¿ëÇؼ­ ¼±Á¡Çü ½ºÄÉÁ층ÀÇ ¹®Á¦¸¦ ÇÇÇÏ°Ô ÇØÁÝ´Ï´Ù.

ÀÌ°ÍÀº À¯¿ëÇÑ Á¢±Ù¹ýÀ̱â´Â ÇÏÁö¸¸, Pth¸¦ »ç¿ëÇÒ ¶§¿¡´Â ºñ¼±Á¡Çü ¾²·¹µå ½ºÄÉÁ층ÀÇ ±¸ÇöÀ» °í·ÁÇØ¾ß ÇÕ´Ï´Ù. ´ÙÀ½Àº ¸î°¡Áö ÇʼöÀûÀÎ »çÇ×À» ¿ä¾àÇÑ °ÍÀÔ´Ï´Ù.

  • Pth´Â ÃÖ°íÀÇ À̽ļºÀ» Á¦°øÇÏÁö¸¸ À¯º°³­ Ư¡À» Á¦°øÇÏÁö´Â ¾Ê½À´Ï´Ù.

    ÀÌ°ÍÀº Pth°¡ ¾²·¹µå¸¦ »ý¼ºÇÏ´Â µ¥ Àͼ÷Çϸ鼭 À̽ļº ÀÖ´Â POSIX/ANSI-C Á¢±Ù¹ýÀ» »ç¿ëÇÏ°í (ÀÌ ¹æ¹ýÀº ¾î¶² Ç÷§Æû¿¡ Á¾¼ÓµÈ ¾î¼Àºí·¯ hackÀÌ ÇÊ¿ä¾ø½À´Ï´Ù.) ºñ¼±Á¡ÇüÀ¸·Î ¾²·¹µå¸¦ ½ºÄÉÁ층Çϱ⠶§¹®ÀÔ´Ï´Ù. (SIGVTALRM°°Àº À̽ļº ¾ø´Â ±â´ÉÀÌ ÇÊ¿ä¾ø½À´Ï´Ù.) ÇÏÁö¸¸, ÀÌ ¹æ¹ýÀÌ ¸ðµç À¯º°³­ ¾²·¹µù Ư¡À» ±¸ÇöÇÒ ¼ö ÀÖ´Â °ÍÀº ¾Æ´Õ´Ï´Ù. ±×·³¿¡µµ ºÒ±¸ÇÏ°í, Pth¿¡¼­ ÀÌ¿ë °¡´ÉÇÑ ±â´ÉµéÀº Æ°Æ°ÇÏ°í ¿ÏÀüÇÑ Æ¯Â¡ÀÇ ¾²·¹µù ¾¾½ºÅÛÀ» Á¦°øÇϱ⿡ ÃæºÐÇÕ´Ï´Ù.

  • Pth´Â À̺¥Æ®·Î ±¸µ¿µÇ´Â ¾îÇø®ÄÉÀ̼ÇÀÇ ÀÀ´ä¼º°ú µ¿½Ã¼ºÀ» Çâ»ó½ÃÅ°Áö¸¸ ´ëÇü ¼öÄ¡ ¿¬»ê(number-crunching) ¾îÇø®ÄÉÀ̼ǿ¡¼­´Â ±×·¸Áö ¾Ê½À´Ï´Ù.

    preemptive scheduling because no unnecessary context switching occurs, as it is the case for preemptive scheduling. That's why Pth is mainly intended for server type applications, although there is no technical restriction.?> ±× ÀÌÀ¯´Â ºñ¼±Á¡Çü ½ºÄÉÁ층 ¶§¹®ÀÔ´Ï´Ù. ´ëÇü ¼öÄ¡ ¿¬»ê ¾îÇø®ÄÉÀ̼ÇÀº ´ë°³ ±ä CPU Á¡À¯½Ã°£(burst) ¶§¹®¿¡ º´Ç༺À» È®º¸Çϱâ À§ÇØ ¼±Á¡Çü ½ºÄÉÁ층À» ÇÊ¿ä·Î ÇÕ´Ï´Ù. ±×·± °æ¿ì, ºñ¼±Á¡Çü ½ºÄÉÁ층Àº (¸í½ÃÀûÀÎ ¾çº¸·Î) ¿À·¡µÈ 'coroutines' °³³ä¸¸À» Áö¿øÇÕ´Ï´Ù. ÇÑÆí, À̺¥Æ®·Î ±¸µ¿µÇ´Â ¾îÇø®ÄÉÀ̼ÇÀº ºñ¼±Á¡Çü ½ºÄÉÁ층À¸·Î Å« À̵æÀ» º¼ ¼ö ÀÖ½À´Ï´Ù. ÀÌ·± ¾îÇø®ÄÉÀ̼ÇÀº ªÀº CPU Á¡À¯½Ã°£°ú ´ë±âÇÏ´Â ¸¹Àº À̺¥Æ®¸¦ °¡Áö¸é¼­, ºÒÇÊ¿äÇÑ ÄÁÅýºÆ® ÀüȯÀÌ ¹ß»ýµÇÁö ¾Ê±â ¶§¹®¿¡ ºñ¼±Á¡Çü ½ºÄÉÁ층ÇÏ¿¡¼­ ´õ ºü¸£°Ô ½ÇÇàÇÕ´Ï´Ù. ÀÌ°ÍÀÌ Pth°¡ ÁÖ·Î ¼­¹ö ÇüÅÂÀÇ ¾îÇø®ÄÉÀ̼ǿ¡ ÀûÇÕÇÑ ÀÌÀ¯ÀÌÁö¸¸, ±â¼ú»óÀÇ Á¦¾àÀÌ ÀÖÁö´Â ¾Ê½À´Ï´Ù.

  • Pth´Â ¾²·¹µå-¾ÈÀü ÇÔ¼ö¸¦ ¿ä±¸ÇÏÁö¸¸ ÀçÁøÀÔ ÇÔ¼ö¸¦ ¿ä±¸ÇÏÁö´Â ¾Ê½À´Ï´Ù.

    ÀÌ ÈǸ¢ÇÑ »ç½ÇÀº ºñ¼±Á¡Çü ½ºÄÉÁ층ÀÇ ¼ºÁú ¶§¹®À̱⵵ ÇÕ´Ï´Ù. ÇÔ¼ö´Â Áß°£¿¡¼­ °¡·Îä±â ´çÇÏÁö ¾ÊÀ¸¸ç ÇÔ¼ö°¡ ¸®ÅÏÇϱâ Àü¿¡´Â ÀçÁøÀÔ µÉ ¼ö ¾ø½À´Ï´Ù. ÀÌ°ÍÀº ¾²·¹µå-¾ÈÀüÀÌ ÀçÁøÀÔ °¡´É¼ºº¸´Ù ÈνŠ´Þ¼ºÇϱ⠽±±â ¶§¹®¿¡ À̽ļº¿¡ Ä¿´Ù¶õ ÀÌÁ¡ÀÌ µË´Ï´Ù. ƯÈ÷ ÀÌ°ÍÀº Pth ÇÏ¿¡¼­ ´õ ¸¹Àº ±âÁ¸ÀÇ ½áµåÆÄƼ ¶óÀ̺귯¸®°¡ ´Ù¸¥ ¾²·¹µù ½Ã½ºÅÛÀÇ °æ¿ìº¸´Ù ºÎÀÛ¿ë¾øÀÌ »ç¿ëµÉ ¼ö ÀÖ´Ù´Â °ÍÀ» ¶æÇÕ´Ï´Ù.

  • Pth´Â Ä¿³ÎÀÇ Áö¿øÀ» ¿ä±¸ÇÏÁö ¾ÊÁö¸¸ ´ÙÁßÇÁ·Î¼¼¼­ ±â±âÀÇ À̵æÀ» ÃëÇÒ ¼ö ¾øÀ» ¼öµµ ÀÖ½À´Ï´Ù.

    ÀÌ°ÍÀº Unix Ä¿³ÎÀÌ Pth ¾²·¹µå¸¦ ÀνÄÇÒ ÇÊ¿ä°¡ ¾ø±â ¶§¹®¿¡ (¿ÏÀüÈ÷ »ç¿ëÀÚ-°ø°£¿¡¼­ ±¸ÇöµÇ±â ¶§¹®¿¡) Pth´Â ´ëºÎºÐÀÇ ¸ðµç Unix Ä¿³Î»ó¿¡¼­ µ¿ÀÛÇÑ´Ù´Â °ÍÀ» ÀǹÌÇÕ´Ï´Ù. ÇÑÆí, ´ÙÁßÇÁ·Î¼¼¼­ÀÇ À̵æÀ» ÃëÇÒ ¸øÇÒ ¼öµµ Àִµ¥, À̸¦ À§Çؼ­´Â Ä¿³Î Áö¿øÀÌ ÇÊ¿äÇϱ⠶§¹®ÀÔ´Ï´Ù. ½ÇÁ¦·Î, ´ÙÁßÇÁ·Î¼¼¼­ ½Ã½ºÅÛÀº µå¹°°í, ¾ÆÁÖ ³ôÀº º´Ç༺ º¸´Ù´Â À̽ļºÀÌ ´ëºÎºÐ ´õ Áß¿äÇϱ⠶§¹®¿¡, ÀÌ°ÍÀº ¹®Á¦°¡ ¾Æ´Õ´Ï´Ù. (¿ªÀÚ ÁÖ: ´ÙÁßÇÁ·Î¼¼¼­ ±â°è¿¡¼­ ´Ù¸¥ Çϳª ÀÌ»óÀÇ CPU°¡ µµ¿òÀÌ µÉ °ÍÀº ºÐ¸íÇÕ´Ï´Ù. ¿¹¸¦ µé¸é, ½ÇÁúÀûÀÎ ÇϺÎÀÇ I/O³ª °ü¸®ÀÚ¿ë Á¢¼Ó, ´Ù¸¥ ÇÁ·Î¼¼½º µîÀ» ´Ù¸¥ CPU°¡ ¸Ã¾Æ¼­ ó¸®ÇÒ ¼ö ÀÖ½À´Ï´Ù.)


4.5. ¾²·¹µåÀÇ »ý¸í ÁÖ±â

Pth API¸¦ ÀÌÇØÇϱâ À§Çؼ­, Pth ¾²·¹µù ½Ã½ºÅÛ¿¡¼­ ¾²·¹µåÀÇ »ý¸í Áֱ⸦ ÀÌÇØÇÏ´Â °ÍÀÌ ¿ì¼±ÀûÀ¸·Î µµ¿òÀÌ µË´Ï´Ù. ÀÌ°ÍÀº ´ÙÀ½°ú °°Àº ¼± ±×·¡ÇÁ·Î Ç¥ÇöÇÒ ¼ö ÀÖ½À´Ï´Ù.

             NEW
              |
              V
      +---> READY ---+
      |       ^      |
      |       |      V
   WAITING <--+-- RUNNING
                     |
      :              V
   SUSPENDED       DEAD
		

rom `starving'.?> »õ·Î¿î ¾²·¹µå°¡ »ý¼ºµÇ¸é ÀÌ ¾²·¹µå´Â ½ºÄÉÁì·¯ÀÇ NEW Å¥·Î ¿Å°ÜÁý´Ï´Ù. ½ºÄÉÁì·¯´Â ÀÌ ¾²·¹µå¸¦ ´ÙÀ½¹ø ó¸® ´Ü°è(dispatching)¿¡¼­ NEW Å¥¿¡¼­ »Ì¾Æ¼­ READY Å¥·Î ¿Å±é´Ï´Ù. ÀÌ Å¥´Â CPU¸¦ Á¡À¯Çϱ⠿øÇÏ´Â ¸ðµç ¾²·¹µå¸¦ ´ã°í ÀÖ½À´Ï´Ù. ¾²·¹µå´Â ¿ì¼±¼øÀ§ ¼øÀ¸·Î Å¥ µË´Ï´Ù. °¢ ó¸® ´Ü°è¿¡¼­, ½ºÄÉÁì·¯´Â Ç×»ó °¡Àå ³ôÀº ¿ì¼±¼øÀ§ÀÇ ¾²·¹µå¸¸À» Á¦°ÅÇÕ´Ï´Ù. ±×¸®°í³ª¼­ ¾²·¹µå°£ÀÇ ¹«ÇÑÁ¤ ´ë±â »óÅÂ(starving)¸¦ ¹æÁöÇϱâ À§Çؼ­ ¸ðµç ³²¾ÆÀÖ´Â ¾²·¹µåÀÇ ¿ì¼±¼øÀ§¸¦ 1¾¿ ³ôÀÔ´Ï´Ù.

queue. Else it is assumed it wants to perform more CPU bursts and immediately enters the READY queue again.?> READY Å¥¿¡¼­ Á¦°ÅµÈ ¾²·¹µå´Â »õ·Î¿î RUNNING ¾²·¹µå°¡ µË´Ï´Ù. (¹°·Ð Ç×»ó ÇϳªÀÇ RUNNING ¾²·¹µå¸¸ÀÌ Á¸ÀçÇÕ´Ï´Ù.) RUNNING ¾²·¹µå¿¡°Ô´Â ½ÇÇà Á¦¾î±ÇÀÌ ÁÖ¾îÁý´Ï´Ù. ÀÌ ¾²·¹µå°¡ ½ÇÇàÀ» ¾çº¸Çϸé (½ÇÇàÀ» ¸í½ÃÀûÀ¸·Î ¾çº¸Çϰųª ¾Ï¹¬ÀûÀ¸·Î ºí·¯Å·µÉ ¼ö ÀÖ´Â ÇÔ¼ö¸¦ È£Ãâ) ¼¼°¡Áö °¡´É¼ºÀÌ ÀÖ½À´Ï´Ù. ¾²·¹µå°¡ Á¾·áµÇ¸é DEAD Å¥·Î À̵¿ÇÏ°í, ´ë±â¸¦ ¿øÇÏ´Â À̺¥Æ®°¡ ÀÖÀ¸¸é WAITING Å¥·Î À̵¿Çϸç, ¾Æ´Ï¸é CPU ¸¦ Á¡À¯Çϱ⠿øÇÑ´Ù°í °¡Á¤Çؼ­ ´Ù½Ã READY Å¥·Î Áï½Ã µé¾î°©´Ï´Ù.

´ÙÀ½ ¾²·¹µå°¡ READY Å¥¿¡¼­ ²¨³»Áö±â Àü¿¡, WAITING Å¥¸¦ ´ë±âÁßÀÎ À̺¥Æ®¸¦ À§Çؼ­ °Ë»çÇÕ´Ï´Ù. Çϳª ÀÌ»óÀÇ À̺¥Æ®°¡ ¹ß»ýÇϸé, À̺¥Æ®¸¦ ´ë±âÁßÀÎ ¾²·¹µå´Â READY Å¥·Î Áï½Ã À̵¿µË´Ï´Ù.

NEW Å¥ÀÇ ¸ñÀûÀº Pth¿¡¼­ ¾²·¹µå°¡ Àý´ë ´Ù¸¥ ¾²·¹µå·Î Á÷Á¢ ÀüȯµÇÁö ¸øÇϵµ·Ï ÇÏ´Â °ÍÀÔ´Ï´Ù. ¾²·¹µå´Â Ç×»ó ½ºÄÉÁì·¯·Î ½ÇÇàÀ» ¾çº¸ÇÏ°í ½ºÄÉÁì·¯°¡ ´ÙÀ½ ¾²·¹µå¸¦ ó¸®Çϵµ·Ï ÇÕ´Ï´Ù. ½ºÄÉÁì·¯°¡ ½ºÄÉÁ층À» À§Çؼ­ ¾²·¹µå¸¦ »ÌÀ» ±âȸ°¡ »ý±æ ¶§±îÁö ±Ý¹æ »ý¼ºµÈ ¾²·¹µå´Â ¾îµð¼±°¡ À¯ÁöµÇ¾î¾ß ÇÕ´Ï´Ù.

DEAD Å¥ÀÇ ¸ñÀûÀº ¾²·¹µå º´ÇÕ(joining)À» Áö¿øÇϱâ À§Çؼ­ ÀÔ´Ï´Ù. ¾²·¹µå°¡ º´ÇÕ ºÒÇÊ¿ä(unjoinable)·Î ÁöÁ¤µÇ¾ú´Ù¸é ¾²·¹µå°¡ Á¾·áµÉ ¶§ ½Ã½ºÅÛ ¹Ù±ùÀ¸·Î ¹Ù·Î ÅðÃâµË´Ï´Ù. ÇÏÁö¸¸ ¾²·¹µå°¡ º´ÇÕ ÇÊ¿ä(joinable)¶ó¸é, ¾²·¹µå´Â DEAD Å¥·Î µé¾î°©´Ï´Ù. ´Ù¸¥ ¾²·¹µå°¡ ÀÌ ¾²·¹µå¿Í º´ÇÕÇÒ ¶§±îÁö ÀÌ Å¥¿¡ ³²°Ô µË´Ï´Ù.

m where it originally came and this way again enters the schedulers scope.?> ¸¶Áö¸·À¸·Î, ¾îÇø®ÄÉÀ̼ÇÀÌ NEW, READY, WAITING Å¥¿¡¼­ ¼öµ¿À¸·Î ¿Å±æ ¼ö Àִ Ư¼öÇÏ°Ô ºÐ¸®µÈ SUSPENDED ¶ó°í ºÒ¸®´Â Å¥°¡ ÀÖ½À´Ï´Ù. ÀÌ Æ¯¼öÇÑ Å¥ÀÇ ¸ñÀûÀº ±× ¾²·¹µåµéÀÌ ¾îÇø®ÄÉÀ̼ǿ¡ ÀÇÇؼ­ Àç½ÇÇà µÉ ¶§±îÁö Àӽ÷ΠÀϽà ÁßÁöµÈ ¾²·¹µå¸¦ ¹Þ¾ÆµéÀÌ´Â °ÍÀÔ´Ï´Ù. ÀϽà ÁßÁöµÈ ¾²·¹µåµéÀº Àӽ÷Π½ºÄÉÁì·¯ÀÇ ¿µ¿ª¿¡¼­ ¿ÏÀüÈ÷ ¹ù¾î³ª Àֱ⠶§¹®¿¡ ½ºÄÉÁ층À̳ª À̺¥Æ® ó¸® ÀÚ¿øÀ» ¼ÒºñÇÏÁö ¾Ê½À´Ï´Ù. ¸¸¾à ¾²·¹µå°¡ Àç½ÇÇàµÈ´Ù¸é, ¿ø·¡ ÀÖ´ø Å¥·Î ´Ù½Ã À̵¿ÇÏ°í ´Ù½Ã ½ºÄÉÁì·¯ÀÇ ¿µ¿ª¿¡ µé¾î°¡°Ô µË´Ï´Ù.


5. APPLICATION PROGRAMMING INTERFACE (API)

´ÙÀ½Àº Pth APIÀÇ ÀÚ¼¼ÇÑ ¼³¸íÀÔ´Ï´Ù. ¾Õ ÀýÀÇ ¼³¸íÀ» ÀÌÇØÇϸé, ÀÌ API·Î ¾²·¹µå¸¦ ÇÁ·Î±×·¡¹ÖÇÏ´Â ¹æ¹ýÀ» ÀÌÇØÇϱ⠽±½À´Ï´Ù. Unix ÇÔ¼öµé°ú ¸¶Âù°¡Áö·Î, Pth ÇÔ¼ö´Â ¿À·ù »óŸ¦ Ç¥½ÃÇϴµ¥ Ư¼öÇÑ ¸®ÅÏ °ªÀ» »ç¿ëÇÏ°í (Æ÷ÀÎÅÍ ÄÁÅؽºÆ®´Â NULL, ºÒ¸° ÄÁÅؽºÆ®´Â FALSE, Á¤¼ö ÄÁÅؽºÆ®´Â -1) errno ½Ã½ºÅÛ º¯¼ö·Î ¿À·ù¿¡ ´ëÇÑ ÀÚ¼¼ÇÑ Á¤º¸¸¦ ¾Ë·ÁÁÝ´Ï´Ù.


5.1. Global Library Management

´ÙÀ½ ÇÔ¼öµéÀº ¶óÀ̺귯¸® Àüü¿¡ ÀÛ¿ëÇÕ´Ï´Ù. ½ºÄÉÁì·¯¸¦ ÃʱâÈ­ÇÏ°í Á¾·áÇϰųª Á¤º¸¸¦ ¾ò´Âµ¥ »ç¿ëÇÕ´Ï´Ù.

  • int pth_init(void);

    Pth ¶óÀ̺귯¸®¸¦ ÃʱâÈ­ÇÕ´Ï´Ù. ¾îÇø®ÄÉÀ̼ǿ¡¼­ óÀ½À¸·Î È£ÃâÇÏ´Â Pth API ÇÔ¼öÀ̸ç, ²À È£ÃâÇÏ¿©¾ß ÇÕ´Ï´Ù. ´ë°³ ¾îÇø®ÄÉÀ̼ÇÀÇ main() ÇÔ¼öÀÇ Ã³À½¿¡¼­ È£ÃâÇÕ´Ï´Ù. ÀÌ°ÍÀº ¾Ï¹¬ÀûÀ¸·Î ³»ºÎÀÇ ½ºÄÉÁì·¯ ¾²·¹µå¸¦ ½ºÆùÇÏ°í ÇöÀç ÇÁ·Î¼¼½ºÀÇ ´ÜÀÏ ½ÇÇà ´ÜÀ§¸¦ ¾²·¹µå('main' ¾²·¹µå)·Î º¯È¯ÇÕ´Ï´Ù. ¼º°øÇϸé TRUE¸¦, ½ÇÆÐÇϸé FALSE¸¦ ¸®ÅÏÇÕ´Ï´Ù.

  • int pth_kill(void);

    This kills the Pth library. It should be the last Pth API function call in an application, but is not really required. It's usually done at the end of the main function of the application. At least, it has to be called from within the main thread. It implicitly kills all threads and transforms back the calling thread into the single execution unit of the underlying process. The usual way to terminate a Pth application is either a simple `pth_exit(0);' in the main thread (which waits for all other threads to terminate, kills the threading system and then terminates the process) or a `pth_kill(); exit(0)' (which immediately kills the threading system and terminates the process). The pth_kill() return immediately with a return code of FALSE if it is not called from within the main thread. Else it kills the threading system and returns TRUE.

  • long pth_ctrl(unsigned long query, ...);

    This is a generalized query/control function for the Pth library. The argument query is a bitmask formed out of one or more PTH_CTRL_XXXX queries. Currently the following queries are supported:

    • PTH_CTRL_GETTHREADS

      This returns the total number of threads currently in existence. This query actually is formed out of the combination of queries for threads in a particular state, i.e., the PTH_CTRL_GETTHREADS query is equal to the OR-combination of all the following specialized queries:

      PTH_CTRL_GETTHREADS_NEW for the number of threads in the new queue (threads created via pth_spawn(3) but still not scheduled once), PTH_CTRL_GETTHREADS_READY for the number of threads in the ready queue (threads who want to do CPU bursts), PTH_CTRL_GETTHREADS_RUNNING for the number of running threads (always just one thread!), PTH_CTRL_GETTHREADS_WAITING for the number of threads in the waiting queue (threads waiting for events), PTH_CTRL_GETTHREADS_SUSPENDED for the number of threads in the suspended queue (threads waiting to be resumed) and PTH_CTRL_GETTHREADS_DEAD for the number of threads in the new queue (terminated threads waiting for a join).

    • PTH_CTRL_GETAVLOAD

      This requires a second argument of type `float *' (pointer to a floating point variable). It stores a floating point value describing the exponential averaged load of the scheduler in this variable. The load is a function from the number of threads in the ready queue of the schedulers dispatching unit. So a load around 1.0 means there is only one ready thread (the standard situation when the application has no high load). A higher load value means there a more threads ready who want to do CPU bursts. The average load value updates once per second only. The return value for this query is always 0.

    • PTH_CTRL_GETPRIO

      This requires a second argument of type `pth_t' which identifies a thread. It returns the priority (ranging from PTH_PRIO_MIN to PTH_PRIO_MAX) of the given thread.

    • PTH_CTRL_GETNAME

      This requires a second argument of type `pth_t' which identifies a thread. It returns the name of the given thread, i.e., the return value of pth_ctrl(3) should be casted to a `char *'.

    • PTH_CTRL_DUMPSTATE

      This requires a second argument of type `FILE *' to which a summary of the internal Pth library state is written to. The main information which is currently written out is the current state of the thread pool.

    The function returns -1 on error.

  • long pth_version(void);

    This function returns a hex-value `0xVRRTLL' which describes the current Pth library version. V is the version, RR the revisions, LL the level and T the type of the level (alphalevel=0, betalevel=1, patchlevel=2, etc). For instance Pth version 1.0b1 is encoded as 0x100101. The reason for this unusual mapping is that this way the version number is steadily increasing. The same value is also available under compile time as PTH_VERSION.


5.2. Thread Attribute Handling

Attribute objects are used in Pth for two things: First stand-alone/unbound attribute objects are used to store attributes for to be spawned threads. Bounded attribute objects are used to modify attributes of already existing threads. The following attribute fields exists in attribute objects:

  • PTH_ATTR_PRIO (read-write) [int]

    Thread Priority between PTH_PRIO_MIN and PTH_PRIO_MAX. The default is PTH_PRIO_STD.

  • PTH_ATTR_NAME (read-write) [char *]

    Name of thread (up to 40 characters are stored only), mainly for debugging purposes.

  • PTH_ATTR_DISPATCHES (read-write) [int]

    In bounded attribute objects, this field is incremented every time the context is switched to the associated thread.

  • PTH_ATTR_JOINABLE (read-write> [int]

    The thread detachment type, TRUE indicates a joinable thread, FALSE indicates a detached thread. When a thread is detached, after termination it is immediately kicked out of the system instead of inserted into the dead queue.

  • PTH_ATTR_CANCEL_STATE (read-write) [unsigned int]

    The thread cancellation state, i.e., a combination of PTH_CANCEL_ENABLE or PTH_CANCEL_DISABLE and PTH_CANCEL_DEFERRED or PTH_CANCEL_ASYNCHRONOUS.

  • PTH_ATTR_STACK_SIZE (read-write) [unsigned int]

    The thread stack size in bytes. Use lower values than 64 KB with great care!

  • PTH_ATTR_STACK_ADDR (read-write) [char *]

    A pointer to the lower address of a chunk of malloc(3)'ed memory for the stack.

  • PTH_ATTR_TIME_SPAWN (read-only) [pth_time_t]

    The time when the thread was spawned. This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_TIME_LAST (read-only) [pth_time_t]

    The time when the thread was last dispatched. This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_TIME_RAN (read-only) [pth_time_t]

    The total time the thread was running. This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_START_FUNC (read-only) [void *(*)(void *)]

    The thread start function. This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_START_ARG (read-only) [void *]

    The thread start argument. This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_STATE (read-only) [pth_state_t]

    The scheduling state of the thread, i.e., either PTH_STATE_NEW, PTH_STATE_READY, PTH_STATE_WAITING, or PTH_STATE_DEAD This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_EVENTS (read-only) [pth_event_t]

    The event ring the thread is waiting for. This can be queried only when the attribute object is bound to a thread.

  • PTH_ATTR_BOUND (read-only) [int]

    Whether the attribute object is bound (TRUE) to a thread or not (FALSE).

The following API functions can be used to handle the attribute objects:

  • pth_attr_t pth_attr_of(pth_t tid);

    This returns a new attribute object bound to thread tid. Any queries on this object directly fetch attributes from tid. And attribute modifications directly change tid. Use such attribute objects to modify existing threads.

  • pth_attr_t pth_attr_new(void);

    This returns a new unbound attribute object. An implicit pth_attr_init() is done on it. Any queries on this object just fetch stored attributes from it. And attribute modifications just change the stored attributes. Use such attribute objects to pre-configure attributes for to be spawned threads.

  • int pth_attr_init(pth_attr_t attr);

    This initializes an attribute object attr to the default values: PTH_ATTR_PRIO := PTH_PRIO_STD, PTH_ATTR_NAME := `unknown', PTH_ATTR_DISPATCHES := 0, PTH_ATTR_JOINABLE := TRUE, PTH_ATTR_CANCELSTATE := PTH_CANCEL_DEFAULT, PTH_ATTR_STACK_SIZE := 64*1024 and PTH_ATTR_STACK_ADDR := NULL. All other PTH_ATTR_* attributes are read-only attributes and don't receive default values in attr, because they exists only for bounded attribute objects.

  • int pth_attr_set(pth_attr_t attr, int field, ...);

    This sets the attribute field field in attr to a value specified as an additional argument on the variable argument list. The following attribute fields and argument pairs can be used:

     PTH_ATTR_PRIO           int
     PTH_ATTR_NAME           char *
     PTH_ATTR_DISPATCHES     int
     PTH_ATTR_JOINABLE       int
     PTH_ATTR_CANCEL_STATE   unsigned int
     PTH_ATTR_STACK_SIZE     unsigned int
     PTH_ATTR_STACK_ADDR     char *

  • int pth_attr_get(pth_attr_t attr, int field, ...);

    This retrieves the attribute field field in attr and stores its value in the variable specified through a pointer in an additional argument on the variable argument list. The following fields and argument pairs can be used:

     PTH_ATTR_PRIO           int *
     PTH_ATTR_NAME           char **
     PTH_ATTR_DISPATCHES     int *
     PTH_ATTR_JOINABLE       int *
     PTH_ATTR_CANCEL_STATE   unsigned int *
     PTH_ATTR_STACK_SIZE     unsigned int *
     PTH_ATTR_STACK_ADDR     char **
     PTH_ATTR_TIME_SPAWN     pth_time_t *
     PTH_ATTR_TIME_LAST      pth_time_t *
     PTH_ATTR_TIME_RAN       pth_time_t *
     PTH_ATTR_START_FUNC     void *(**)(void *)
     PTH_ATTR_START_ARG      void **
     PTH_ATTR_STATE          pth_state_t *
     PTH_ATTR_EVENTS         pth_event_t *
     PTH_ATTR_BOUND          int *

  • int pth_attr_destroy(pth_attr_t attr);

    This destroys a attribute object attr. After this attr is no longer a valid attribute object.


5.3. Thread Control

The following functions control the threading itself and make up the main API of the Pth library.

  • pth_t pth_spawn(pth_attr_t attr, void *(*entry)(void *), void *arg);

    This spawns a new thread with the attributes given in attr (or PTH_ATTR_DEFAULT for default attributes - which means that thread priority, joinability and cancel state are inherited from the current thread) with the starting point at routine entry; the dispatch count is not inherited from the current thread if attr is not specified - rather, it is initialized to zero. This entry routine is called as `pth_exit(entry(arg))' inside the new thread unit, i.e., entry's return value is fed to an implicit pth_exit(3). So the thread can also exit by just returning. Nevertheless the thread can also exit explicitly at any time by calling pth_exit(3). But keep in mind that calling the POSIX function exit(3) still terminates the complete process and not just the current thread.

    There is no Pth-internal limit on the number of threads one can spawn, except the limit implied by the available virtual memory. Pth internally keeps track of thread in dynamic data structures. The function returns NULL on error.

  • int pth_once(pth_once_t *ctrlvar, void (*func)(void *), void *arg);

    This is a convenience function which uses a control variable of type pth_once_t to make sure a constructor function func is called only once as `func(arg)' in the system. In other words: Only the first call to pth_once(3) by any thread in the system succeeds. The variable referenced via ctrlvar should be declared as `pth_once_t variable-name = PTH_ONCE_INIT;' before calling this function.

  • pth_t pth_self(void);

    This just returns the unique thread handle of the currently running thread. This handle itself has to be treated as an opaque entity by the application. It's usually used as an argument to other functions who require an argument of type pth_t.

  • int pth_suspend(pth_t tid);

    This suspends a thread tid until it is manually resumed again via pth_resume(3). For this, the thread is moved to the SUSPENDED queue and this way is completely out of the scheduler's event handling and thread dispatching scope. Suspending the current thread is not allowed. The function returns TRUE on success and FALSE on errors.

  • int pth_resume(pth_t tid);

    This function resumes a previously suspended thread tid, i.e. tid has to stay on the SUSPENDED queue. The thread is moved to the NEW, READY or WAITING queue (dependent on what its state was when the pth_suspend(3) call were made) and this way again enters the event handling and thread dispatching scope of the scheduler. The function returns TRUE on success and FALSE on errors.

  • int pth_raise(pth_t tid, int sig)

    This function raises a signal for delivery to thread tid only. When one just raises a signal via raise(3) or kill(2), its delivered to an arbitrary thread which has this signal not blocked. With pth_raise(3) one can send a signal to a thread and its guarantees that only this thread gets the signal delivered. But keep in mind that nevertheless the signals action is still configured process-wide. When sig is 0 plain thread checking is performed, i.e., `pth_raise(tid, 0)' returns TRUE when thread tid still exists in the PTH system but doesn't send any signal to it.

  • int pth_yield(pth_t tid);

    This explicitly yields back the execution control to the scheduler thread. Usually the execution is implicitly transferred back to the scheduler when a thread waits for an event. But when a thread has to do larger CPU bursts, it can be reasonable to interrupt it explicitly by doing a few pth_yield(3) calls to give other threads a chance to execute, too. This obviously is the cooperating part of Pth. A thread has not to yield execution, of course. But when you want to program a server application with good response times the threads should be cooperative, i.e., when they should split their CPU bursts into smaller units with this call.

    Usually one specifies tid as NULL to indicate to the scheduler that it can freely decide which thread to dispatch next. But if one wants to indicate to the scheduler that a particular thread should be favored on the next dispatching step, one can specify this thread explicitly. This allows the usage of the old concept of coroutines where a thread/routine switches to a particular cooperating thread. If tid is not NULL and points to a new or ready thread, it is guaranteed that this thread receives execution control on the next dispatching step. If tid is in a different state (that is, not in PTH_STATE_NEW or PTH_STATE_READY) an error is reported.

    The function usually returns TRUE for success and only FALSE (with errno set to EINVAL) if tid specified an invalid or still not new or ready thread.

  • int pth_nap(pth_time_t naptime);

    This functions suspends the execution of the current thread until naptime is elapsed. naptime is of type pth_time_t and this way has theoretically a resolution of one microsecond. In practice you should neither rely on this nor that the thread is awakened exactly after naptime has elapsed. It's only guarantees that the thread will sleep at least naptime. But because of the non-preemptive nature of Pth it can last longer (when another thread kept the CPU for a long time). Additionally the resolution is dependent of the implementation of timers by the operating system and these usually have only a resolution of 10 microseconds or larger. But usually this isn't important for an application unless it tries to use this facility for real time tasks.

  • int pth_wait(pth_event_t ev);

    This is the link between the scheduler and the event facility (see below for the various pth_event_xxx() functions). It's modeled like select(2), i.e., one gives this function one or more events (in the event ring specified by ev) on which the current thread wants to wait. The scheduler awakes the thread when one ore more of them occurred or failed after tagging them as such. The ev argument is a pointer to an event ring which isn't changed except for the tagging. pth_wait(3) returns the number of occurred or failed events and the application can use pth_event_status(3) to test which events occurred or failed.

  • int pth_cancel(pth_t tid);

    This cancels a thread tid. How the cancellation is done depends on the cancellation state of tid which the thread can configure itself. When its state is PTH_CANCEL_DISABLE a cancellation request is just made pending. When it is PTH_CANCEL_ENABLE it depends on the cancellation type what is performed. When its PTH_CANCEL_DEFERRED again the cancellation request is just made pending. But when its PTH_CANCEL_ASYNCHRONOUS the thread is immediately canceled before pth_cancel(3) returns. The effect of a thread cancellation is equal to implicitly forcing the thread to call `pth_exit(PTH_CANCELED)' at one of his cancellation points. In Pth thread enter a cancellation point either explicitly via pth_cancel_point(3) or implicitly by waiting for an event.

  • int pth_abort(pth_t tid);

    This is the cruel way to cancel a thread tid. When it's already dead and waits to be joined it just joins it (via `pth_join(tid, NULL)') and this way kicks it out of the system. Else it forces the thread to be not joinable and to allow asynchronous cancellation and then cancels it via `pth_cancel(tid)'.

  • int pth_join(pth_t tid, void **value);

    This joins the current thread with the thread specified via tid. It first suspends the current thread until the tid thread has terminated. Then it is awakened and stores the value of tid's pth_exit(3) call into *value (if value and not NULL) and returns to the caller. A thread can be joined only when it has the attribute PTH_ATTR_JOINABLE set to TRUE (the default). A thread can only be joined once, i.e., after the pth_join(3) call the thread tid is completely removed from the system.

  • void pth_exit(void *value);

    This terminates the current thread. Whether it's immediately removed from the system or inserted into the dead queue of the scheduler depends on its join type which was specified at spawning time. If it has the attribute PTH_ATTR_JOINABLE set to FALSE, it's immediately removed and value is ignored. Else the thread is inserted into the dead queue and value remembered for a subsequent pth_join(3) call by another thread.


5.4. Utilities

Utility functions.

  • int pth_fdmode(int fd, int mode); This switches the non-blocking mode flag on file descriptor fd. The argument mode can be PTH_FDMODE_BLOCK for switching fd into blocking I/O mode, PTH_FDMODE_NONBLOCK for switching fd into non-blocking I/O mode or PTH_FDMODE_POLL for just polling the current mode. The current mode is returned (either PTH_FDMODE_BLOCK or PTH_FDMODE_NONBLOCK) or PTH_FDMODE_ERROR on error. Keep in mind that since Pth 1.1 there is no longer a requirement to manually switch a file descriptor into non-blocking mode in order to use it. This is automatically done temporarily inside Pth. Instead when you now switch a file descriptor explicitly into non-blocking mode, pth_read(3) or pth_write(3) will never block the current thread.

  • pth_time_t pth_time(long sec, long usec);

    This is a constructor for a pth_time_t structure which is a convenient function to avoid temporary structure values. It returns a pth_time_t structure which holds the absolute time value specified by sec and usec.

  • pth_time_t pth_timeout(long sec, long usec);

    This is a constructor for a pth_time_t structure which is a convenient function to avoid temporary structure values. It returns a pth_time_t structure which holds the absolute time value calculated by adding sec and usec to the current time.

  • Sfdisc_t *pth_sfiodisc(void);

    This functions is always available, but only reasonably usable when Pth was built with Sfio support (--with-sfio option) and PTH_EXT_SFIO is then defined by pth.h. It is useful for applications which want to use the comprehensive Sfio I/O library with the Pth threading library. Then this function can be used to get an Sfio discipline structure (Sfdisc_t) which can be pushed onto Sfio streams (Sfio_t) in order to let this stream use pth_read(3)/pth_write(2) instead of read(2)/write(2). The benefit is that this way I/O on the Sfio stream does only block the current thread instead of the whole process. The application has to free(3) the Sfdisc_t structure when it is no longer needed. The Sfio package can be found at http://www.research.att.com/sw/tools/sfio/.


5.5. Cancellation Management

Pth supports POSIX style thread cancellation via pth_cancel(3) and the following two related functions:

  • void pth_cancel_state(int newstate, int *oldstate);

    This manages the cancellation state of the current thread. When oldstate is not NULL the function stores the old cancellation state under the variable pointed to by oldstate. When newstate is not 0 it sets the new cancellation state. oldstate is created before newstate is set. A state is a combination of PTH_CANCEL_ENABLE or PTH_CANCEL_DISABLE and PTH_CANCEL_DEFERRED or PTH_CANCEL_ASYNCHRONOUS. PTH_CANCEL_ENABLE|PTH_CANCEL_DEFERRED (or PTH_CANCEL_DEFAULT) is the default state where cancellation is possible but only at cancellation points. Use PTH_CANCEL_DISABLE to complete disable cancellation for a thread and PTH_CANCEL_ASYNCHRONOUS for allowing asynchronous cancellations, i.e., cancellations which can happen at any time.

  • void pth_cancel_point(void);

    This explicitly enter a cancellation point. When the current cancellation state is PTH_CANCEL_DISABLE or no cancellation request is pending, this has no side-effect and returns immediately. Else it calls `pth_exit(PTH_CANCELED)'.


5.6. Event Handling

Pth has a very flexible event facility which is linked into the scheduler through the pth_wait(3) function. The following functions provide the handling of event rings.

  • pth_event_t pth_event(unsigned long spec, ...);

    This creates a new event ring consisting of a single initial event. The type of the generated event is specified by spec. The following types are available:

    • PTH_EVENT_FD

      This is a file descriptor event. One or more of PTH_UNTIL_FD_READABLE, PTH_UNTIL_FD_WRITEABLE or PTH_UNTIL_FD_EXCEPTION have to be OR-ed into spec to specify on which state of the file descriptor you want to wait. The file descriptor itself has to be given as an additional argument. Example: `pth_event(PTH_EVENT_FD|PTH_UNTIL_FD_READABLE, fd)'.

    • PTH_EVENT_SELECT

      This is a multiple file descriptor event modeled directly after the select(2) call (actually it is also used to implement pth_select(3) internally). It's a convenient way to wait for a large set of file descriptors at once and at each file descriptor for a different type of state. Additionally as a nice side-effect one receives the number of file descriptors which causes the event to be occurred (using BSD semantics, i.e., when a file descriptor occurred in two sets it's counted twice). The arguments correspond directly to the select(2) function arguments except that there is no timeout argument (because timeouts already can be handled via PTH_EVENT_TIME events).

      Example: `pth_event(PTH_EVENT_SELECT, rc, nfd, rfds, wfds, efds)' where rc has to be of type `int *', nfd has to be of type `int' and rfds, wfds and efds have to be of type `fd_set *' (see select(2)). The number of occurred file descriptors are stored in rc.

    • PTH_EVENT_SIGS

      This is a signal set event. The two additional arguments have to be a pointer to a signal set (type `sigset_t *') and a pointer to a signal number variable (type `int *'). This event waits until one of the signals in the signal set occurred. As a result the occurred signal number is stored in the second additional argument. Keep in mind that the Pth scheduler doesn't block signals automatically. So when you want to wait for a signal with this event you've to block it via sigprocmask(2) or it will be delivered without your notice. Example: `sigemptyset(set); sigaddset(set, SIGINT); pth_event(PTH_EVENT_SIG, set, sig);'.

    • PTH_EVENT_TIME

      This is a time point event. The additional argument has to be of type pth_time_t (usually on-the-fly generated via pth_time(3)). This events waits until the specified time point has elapsed. Keep in mind that the value is an absolute time point and not an offset. When you want to wait for a specified amount of time, you've to add the current time to the offset (usually on-the-fly achieved via pth_timeout(3)). Example: `pth_event(PTH_EVENT_TIME, pth_timeout(2,0))'.

    • PTH_EVENT_MSG

      This is a message port event. The additional argument has to be of type pth_msgport_t. This events waits until one or more messages were received on the specified message port. Example: `pth_event(PTH_EVENT_MSG, mp)'.

    • PTH_EVENT_TID

      This is a thread event. The additional argument has to be of type pth_t. One of PTH_UNTIL_TID_NEW, PTH_UNTIL_TID_READY, PTH_UNTIL_TID_WAITING or PTH_UNTIL_TID_DEAD has to be OR-ed into spec to specify on which state of the thread you want to wait. Example: `pth_event(PTH_EVENT_TID|PTH_UNTIL_TID_DEAD, tid)'.

    • PTH_EVENT_FUNC

      This is a custom callback function event. Three additional arguments have to be given with the following types: `int (*)(void *)', `void *' and `pth_time_t'. The first is a function pointer to a check function and the second argument is a user-supplied context value which is passed to this function. The scheduler calls this function on a regular basis (on his own scheduler stack, so be very careful!) and the thread is kept sleeping while the function returns FALSE. Once it returned TRUE the thread will be awakened. The check interval is defined by the third argument, i.e., the check function is polled again not until this amount of time elapsed. Example: `pth_event(PTH_EVENT_FUNC, func, arg, pth_time(0,500000))'.

  • unsigned long pth_event_typeof(pth_event_t ev);

    This returns the type of event ev. It's a combination of the describing PTH_EVENT_XX and PTH_UNTIL_XX value. This is especially useful to know which arguments have to be supplied to the pth_event_extract(3) function.

  • int pth_event_extract(pth_event_t ev, ...);

    When pth_event(3) is treated like sprintf(3), then this function is sscanf(3), i.e., it is the inverse operation of pth_event(3). This means that it can be used to extract the ingredients of an event. The ingredients are stored into variables which are given as pointers on the variable argument list. Which pointers have to be present depends on the event type and has to be determined by the caller before via pth_event_typeof(3).

    To make it clear, when you constructed ev via `ev = pth_event(PTH_EVENT_FD, fd);' you have to extract it via `pth_event_extract(ev, fd)', etc. For multiple arguments of an event the order of the pointer arguments is the same as for pth_event(3). But always keep in mind that you have to always supply pointers to variables and these variables have to be of the same type as the argument of pth_event(3) required.

  • pth_event_t pth_event_concat(pth_event_t ev, ...);

    This concatenates one or more additional event rings to the event ring ev and returns ev. The end of the argument list has to be marked with a NULL argument. Use this function to create real events rings out of the single-event rings created by pth_event(3).

  • pth_event_t pth_event_isolate(pth_event_t ev);

    This isolates the event ev from possibly appended events in the event ring. When in ev only one event exists, this returns NULL. When remaining events exists, they form a new event ring which is returned.

  • pth_event_t pth_event_walk(pth_event_t ev, int direction);

    This walks to the next (when direction is PTH_WALK_NEXT) or previews (when direction is PTH_WALK_PREV) event in the event ring ev and returns this new reached event. Additionally PTH_UNTIL_OCCURRED can be OR-ed into direction to walk to the next/previous occurred event in the ring ev.

  • pth_status_t pth_event_status(pth_event_t ev);

    This returns the status of event ev. This is a fast operation because only a tag on ev is checked which was either set or still not set by the scheduler. In other words: This doesn't check the event itself, it just checks the last knowledge of the scheduler. The possible returned status codes are: PTH_STATUS_PENDING (event is still pending), PTH_STATUS_OCCURRED (event successfully occurred), PTH_STATUS_FAILED (event failed).

  • int pth_event_free(pth_event_t ev, int mode);

    This deallocates the event ev (when mode is PTH_FREE_THIS) or all events appended to the event ring under ev (when mode is PTH_FREE_ALL).


5.7. Key-Based Storage

The following functions provide thread-local storage through unique keys similar to the POSIX Pthread API. Use this for thread specific global data.

  • int pth_key_create(pth_key_t *key, void (*func)(void *));

    This created a new unique key and stores it in key. Additionally func can specify a destructor function which is called on the current threads termination with the key.

  • int pth_key_delete(pth_key_t key);

    This explicitly destroys a key key.

  • int pth_key_setdata(pth_key_t key, const void *value);

    This stores value under key.

  • void *pth_key_getdata(pth_key_t key);

    This retrieves the value under key.


5.8. Message Port Communication

The following functions provide message ports which can be used for efficient and flexible inter-thread communication.

  • pth_msgport_t pth_msgport_create(const char *name);

    This returns a pointer to a new message port. If name name is not NULL, the name can be used by other threads via pth_msgport_find(3) to find the message port in case they do not know directly the pointer to the message port.

  • void pth_msgport_destroy(pth_msgport_t mp);

    This destroys a message port mp. Before all pending messages on it are replied to their origin message port.

  • pth_msgport_t pth_msgport_find(const char *name);

    This finds a message port in the system by name and returns the pointer to it.

  • int pth_msgport_pending(pth_msgport_t mp);

    This returns the number of pending messages on message port mp.

  • int pth_msgport_put(pth_msgport_t mp, pth_message_t *m);

    This puts (or sends) a message m to message port mp.

  • pth_message_t *pth_msgport_get(pth_msgport_t mp);

    This gets (or receives) the top message from message port mp. Incoming messages are always kept in a queue, so there can be more pending messages, of course.

  • int pth_msgport_reply(pth_message_t *m);

    This replies a message m to the message port of the sender.


5.9. Thread Cleanups

Per-thread cleanup functions.

  • int pth_cleanup_push(void (*handler)(void *), void *arg);

    This pushes the routine handler onto the stack of cleanup routines for the current thread. These routines are called in LIFO order when the thread terminates.

  • int pth_cleanup_pop(int execute);

    This pops the top-most routine from the stack of cleanup routines for the current thread. When execute is TRUE the routine is additionally called.


5.10. Process Forking

The following functions provide some special support for process forking situations inside the threading environment.

  • int pth_atfork_push(void (*prepare)(void *), void (*)(void *parent), void (*)(void *child), void *arg);

    This function declares forking handlers to be called before and after pth_fork(3), in the context of the thread that called pth_fork(3). The prepare handler is called before fork(2) processing commences. The parent handler is called after fork(2) processing completes in the parent process. The child handler is called after fork(2) processing completed in the child process. If no handling is desired at one or more of these three points, the corresponding handler can be given as NULL. Each handler is called with arg as the argument.

    The order of calls to pth_atfork_push(3) is significant. The parent and child handlers are called in the order in which they were established by calls to pth_atfork_push(3), i.e., FIFO. The prepare fork handlers are called in the opposite order, i.e., LIFO.

  • int pth_atfork_pop(void);

    This removes the top-most handlers on the forking handler stack which were established with the last pth_atfork_push(3) call. It returns FALSE when no more handlers couldn't be removed from the stack.

  • pid_t pth_fork(void);

    This is a variant of fork(2) with the difference that the current thread only is forked into a separate process, i.e., in the parent process nothing changes while in the child process all threads are gone except for the scheduler and the calling thread. When you really want to duplicate all threads in the current process you should use fork(2) directly. But this is usually not reasonable. Additionally this function takes care of forking handlers as established by pth_fork_push(3).


5.11. Synchronization

The following functions provide synchronization support via mutual exclusion locks (mutex), read-write locks (rwlock), condition variables (cond) and barriers (barrier). Keep in mind that in a non-preemptive threading system like Pth this might sound unnecessary at the first look, because a thread isn't interrupted by the system. Actually when you have a critical code section which doesn't contain any pth_xxx() functions, you don't need any mutex to protect it, of course.

But when your critical code section contains any pth_xxx() function the chance is high that these temporarily switch to the scheduler. And this way other threads can make progress and enter your critical code section, too. This is especially true for critical code sections which implicitly or explicitly use the event mechanism.

  • int pth_mutex_init(pth_mutex_t *mutex);

    This dynamically initializes a mutex variable of type `pth_mutex_t'. Alternatively one can also use static initialization via `pth_mutex_t mutex = PTH_MUTEX_INIT'.

  • int pth_mutex_acquire(pth_mutex_t *mutex, int try, pth_event_t ev);

    This acquires a mutex mutex. If the mutex is already locked by another thread, the current threads execution is suspended until the mutex is unlocked again or additionally the extra events in ev occurred (when ev is not NULL). Recursive locking is explicitly supported, i.e., a thread is allowed to acquire a mutex more than once before its released. But it then also has be released the same number of times until the mutex is again lockable by others. When try is TRUE this function never suspends execution. Instead it returns FALSE with errno set to EBUSY.

  • int pth_mutex_release(pth_mutex_t *mutex);

    This decrements the recursion locking count on mutex and when it is zero it releases the mutex mutex.

  • int pth_rwlock_init(pth_rwlock_t *rwlock);

    This dynamically initializes a read-write lock variable of type `pth_rwlock_t'. Alternatively one can also use static initialization via `pth_rwlock_t rwlock = PTH_RWLOCK_INIT'.

  • int pth_rwlock_acquire(pth_rwlock_t *rwlock, int op, int try, pth_event_t ev);

    This acquires a read-only (when op is PTH_RWLOCK_RD) or a read-write (when op is PTH_RWLOCK_RW) lock rwlock. When the lock is only locked by other threads in read-only mode, the lock succeeds. But when one thread holds a read-write lock, all locking attempts suspend the current thread until this lock is released again. Additionally in ev events can be given to let the locking timeout, etc. When try is TRUE this function never suspends execution. Instead it returns FALSE with errno set to EBUSY.

  • int pth_rwlock_release(pth_rwlock_t *rwlock);

    This releases a previously acquired (read-only or read-write) lock.

  • int pth_cond_init(pth_cond_t *cond);

    This dynamically initializes a condition variable variable of type `pth_cond_t'. Alternatively one can also use static initialization via `pth_cond_t cond = PTH_COND_INIT'.

  • int pth_cond_await(pth_cond_t *cond, pth_mutex_t *mutex, pth_event_t ev);

    This awaits a condition situation. The caller has to follow the semantics of the POSIX condition variables: mutex has to be acquired before this function is called. The execution of the current thread is then suspended either until the events in ev occurred (when ev is not NULL) or cond was notified by another thread via pth_cond_notify(3). While the thread is waiting, mutex is released. Before it returns mutex is reacquired.

  • int pth_cond_notify(pth_cond_t *cond, int broadcast);

    This notified one or all threads which are waiting on cond. When broadcast is TRUE all thread are notified, else only a single (unspecified) one.

  • int pth_barrier_init(pth_barrier_t *barrier, int threshold);

    This dynamically initializes a barrier variable of type `pth_barrier_t'. Alternatively one can also use static initialization via `pth_barrier_t barrier = PTH_BARRIER_INIT(threadhold)'.

  • int pth_barrier_reach(pth_barrier_t *barrier);

    This function reaches a barrier barrier. If this is the last thread (as specified by threshold on init of barrier) all threads are awakened. Else the current thread is suspended until the last thread reached the barrier and this way awakes all threads. The function returns (beside FALSE on error) the value TRUE for any thread which neither reached the barrier as the first nor the last thread; PTH_BARRIER_HEADLIGHT for the thread which reached the barrier as the first thread and PTH_BARRIER_TAILLIGHT for the thread which reached the barrier as the last thread.


5.12. User-Space Context

The following functions provide a stand-alone sub-API for user-space context switching. It internally is based on the same underlying machine context switching mechanism the threads in GNU Pth are based on. Hence these functions you can use for implementing your own simple user-space threads. The pth_uctx_t context is somewhat modeled after POSIX ucontext(3).

The time required to create (via pth_uctx_make(3)) a user-space context can range from just a few microseconds up to a more dramatical time (depending on the machine context switching method which is available on the platform). On the other hand, the raw performance in switching the user-space contexts is always very good (nearly independent of the used machine context switching method). For instance, on an Intel Pentium-III CPU with 800Mhz running under FreeBSD 4 one usually achieves about 260,000 user-space context switches (via pth_uctx_switch(3)) per second.

  • int pth_uctx_create(pth_uctx_t *uctx);

    This function creates a user-space context and stores it into uctx. There is still no underlying user-space context configured. You still have to do this with pth_uctx_make(3) or pth_uctx_set(3). On success, this function returns TRUE, else FALSE.

  • int pth_uctx_make(pth_uctx_t uctx, char *sk_addr, size_t sk_size, const sigset_t *sigmask, void (*start_func)(void *), void *start_arg, pth_uctx_t uctx_after);

    This function makes a new user-space context in uctx which will operate on the run-time stack sk_addr (which is of maximum size sk_size), with the signals in sigmask blocked (if sigmask is not NULL) and starting to execute with the call start_func(start_arg). If sk_addr is NULL, a stack is dynamically allocated. The stack size sk_size has to be at least 16384 (16KB). If the start function start_func returns and uctx_after is not NULL, an implicit user-space context switch to this context is performed. Else (if uctx_after is NULL) the process is terminated with exit(3). This function is somewhat modeled after POSIX makecontext(3). On success, this function returns TRUE, else FALSE.

  • int pth_uctx_save(pth_uctx_t uctx);

    This function saves the current user-space context in uctx for later restoring by either pth_uctx_restore(3) or pth_uctx_switch(3). This function is somewhat modeled after POSIX getcontext(3). If uctx is NULL, FALSE is returned instead of TRUE. This is the only error possible.

  • int pth_uctx_restore(pth_uctx_t uctx);

    This function restores the current user-space context from uctx, which previously had to be set with either pth_uctx_make(3) or pth_uctx_save(3). This function is somewhat modeled after POSIX setcontext(3). If uctx is NULL or uctx contains no valid user-space context, FALSE is returned instead of TRUE. These are the only errors possible.

  • int pth_uctx_switch(pth_uctx_t uctx_from, pth_uctx_t uctx_to);

    This function saves the current user-space context in uctx_from for later restoring by either pth_uctx_restore(3) or pth_uctx_switch(3) and restores the new user-space context from uctx, which previously had to be set with either pth_uctx_make(3) or pth_uctx_save(3). This function is somewhat modeled after POSIX swapcontext(3). If uctx_from or uctx_to are NULL or if uctx_to contains no valid user-space context, FALSE is returned instead of TRUE. These are the only errors possible.

  • int pth_uctx_destroy(pth_uctx_t uctx);

    This function destroys the user-space context in uctx. The run-time stack associated with the user-space context is deallocated only if it was given by the application (see sk_addr of pth_uctx_create(3)). If uctx is NULL, FALSE is returned instead of TRUE. This is the only error possible.


5.13. Generalized POSIX Replacement API

The following functions are generalized replacements functions for the POSIX API, i.e., they are similar to the functions under `Standard POSIX Replacement API' but all have an additional event argument which can be used for timeouts, etc.

  • int pth_sigwait_ev(const sigset_t *set, int *sig, pth_event_t ev);

    This is equal to pth_sigwait(3) (see below), but has an additional event argument ev. When pth_sigwait(3) suspends the current threads execution it usually only uses the signal event on set to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • int pth_connect_ev(int s, const struct sockaddr *addr, socklen_t addrlen, pth_event_t ev);

    This is equal to pth_connect(3) (see below), but has an additional event argument ev. When pth_connect(3) suspends the current threads execution it usually only uses the I/O event on s to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • int pth_accept_ev(int s, struct sockaddr *addr, socklen_t *addrlen, pth_event_t ev);

    This is equal to pth_accept(3) (see below), but has an additional event argument ev. When pth_accept(3) suspends the current threads execution it usually only uses the I/O event on s to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • int pth_select_ev(int nfd, fd_set *rfds, fd_set *wfds, fd_set *efds, struct timeval *timeout, pth_event_t ev);

    This is equal to pth_select(3) (see below), but has an additional event argument ev. When pth_select(3) suspends the current threads execution it usually only uses the I/O event on rfds, wfds and efds to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • int pth_poll_ev(struct pollfd *fds, unsigned int nfd, int timeout, pth_event_t ev);

    This is equal to pth_poll(3) (see below), but has an additional event argument ev. When pth_poll(3) suspends the current threads execution it usually only uses the I/O event on fds to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_read_ev(int fd, void *buf, size_t nbytes, pth_event_t ev);

    This is equal to pth_read(3) (see below), but has an additional event argument ev. When pth_read(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_readv_ev(int fd, const struct iovec *iovec, int iovcnt, pth_event_t ev);

    This is equal to pth_readv(3) (see below), but has an additional event argument ev. When pth_readv(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_write_ev(int fd, const void *buf, size_t nbytes, pth_event_t ev);

    This is equal to pth_write(3) (see below), but has an additional event argument ev. When pth_write(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_writev_ev(int fd, const struct iovec *iovec, int iovcnt, pth_event_t ev);

    This is equal to pth_writev(3) (see below), but has an additional event argument ev. When pth_writev(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_recv_ev(int fd, void *buf, size_t nbytes, int flags, pth_event_t ev);

    This is equal to pth_recv(3) (see below), but has an additional event argument ev. When pth_recv(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_recvfrom_ev(int fd, void *buf, size_t nbytes, int flags, struct sockaddr *from, socklen_t *fromlen, pth_event_t ev);

    This is equal to pth_recvfrom(3) (see below), but has an additional event argument ev. When pth_recvfrom(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_send_ev(int fd, const void *buf, size_t nbytes, int flags, pth_event_t ev);

    This is equal to pth_send(3) (see below), but has an additional event argument ev. When pth_send(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).

  • ssize_t pth_sendto_ev(int fd, const void *buf, size_t nbytes, int flags, const struct sockaddr *to, socklen_t tolen, pth_event_t ev);

    This is equal to pth_sendto(3) (see below), but has an additional event argument ev. When pth_sendto(3) suspends the current threads execution it usually only uses the I/O event on fd to awake. With this function any number of extra events can be used to awake the current thread (remember that ev actually is an event ring).


5.14. Standard POSIX Replacement API

The following functions are standard replacements functions for the POSIX API. The difference is mainly that they suspend the current thread only instead of the whole process in case the file descriptors will block.

  • int pth_nanosleep(const struct timespec *rqtp, struct timespec *rmtp);

    This is a variant of the POSIX nanosleep(3) function. It suspends the current threads execution until the amount of time in rqtp elapsed. The thread is guaranteed to not wake up before this time, but because of the non-preemptive scheduling nature of Pth, it can be awakened later, of course. If rmtp is not NULL, the timespec structure it references is updated to contain the unslept amount (the request time minus the time actually slept time). The difference between nanosleep(3) and pth_nanosleep(3) is that that pth_nanosleep(3) suspends only the execution of the current thread and not the whole process.

  • int pth_usleep(unsigned int usec);

    This is a variant of the 4.3BSD usleep(3) function. It suspends the current threads execution until usec microseconds (= usec*1/1000000 sec) elapsed. The thread is guaranteed to not wake up before this time, but because of the non-preemptive scheduling nature of Pth, it can be awakened later, of course. The difference between usleep(3) and pth_usleep(3) is that that pth_usleep(3) suspends only the execution of the current thread and not the whole process.

  • unsigned int pth_sleep(unsigned int sec);

    This is a variant of the POSIX sleep(3) function. It suspends the current threads execution until sec seconds elapsed. The thread is guaranteed to not wake up before this time, but because of the non-preemptive scheduling nature of Pth, it can be awakened later, of course. The difference between sleep(3) and pth_sleep(3) is that pth_sleep(3) suspends only the execution of the current thread and not the whole process.

  • pid_t pth_waitpid(pid_t pid, int *status, int options);

    This is a variant of the POSIX waitpid(2) function. It suspends the current threads execution until status information is available for a terminated child process pid. The difference between waitpid(2) and pth_waitpid(3) is that pth_waitpid(3) suspends only the execution of the current thread and not the whole process. For more details about the arguments and return code semantics see waitpid(2).

  • int pth_system(const char *cmd);

    This is a variant of the POSIX system(3) function. It executes the shell command cmd with Bourne Shell (sh) and suspends the current threads execution until this command terminates. The difference between system(3) and pth_system(3) is that pth_system(3) suspends only the execution of the current thread and not the whole process. For more details about the arguments and return code semantics see system(3).

  • int pth_sigmask(int how, const sigset_t *set, sigset_t *oset)

    This is the Pth thread-related equivalent of POSIX sigprocmask(2) respectively pthread_sigmask(3). The arguments how, set and oset directly relate to sigprocmask(2), because Pth internally just uses sigprocmask(2) here. So alternatively you can also directly call sigprocmask(2), but for consistency reasons you should use this function pth_sigmask(3).

  • int pth_sigwait(const sigset_t *set, int *sig);

    This is a variant of the POSIX.1c sigwait(3) function. It suspends the current threads execution until a signal in set occurred and stores the signal number in sig. The important point is that the signal is not delivered to a signal handler. Instead it's caught by the scheduler only in order to awake the pth_sigwait() call. The trick and noticeable point here is that this way you get an asynchronous aware application that is written completely synchronously. When you think about the problem of asynchronous safe functions you should recognize that this is a great benefit.

  • int pth_connect(int s, const struct sockaddr *addr, socklen_t addrlen);

    This is a variant of the 4.2BSD connect(2) function. It establishes a connection on a socket s to target specified in addr and addrlen. The difference between connect(2) and pth_connect(3) is that pth_connect(3) suspends only the execution of the current thread and not the whole process. For more details about the arguments and return code semantics see connect(2).

  • int pth_accept(int s, struct sockaddr *addr, socklen_t *addrlen);

    This is a variant of the 4.2BSD accept(2) function. It accepts a connection on a socket by extracting the first connection request on the queue of pending connections, creating a new socket with the same properties of s and allocates a new file descriptor for the socket (which is returned). The difference between accept(2) and pth_accept(3) is that pth_accept(3) suspends only the execution of the current thread and not the whole process. For more details about the arguments and return code semantics see accept(2).

  • int pth_select(int nfd, fd_set *rfds, fd_set *wfds, fd_set *efds, struct timeval *timeout);

    This is a variant of the 4.2BSD select(2) function. It examines the I/O descriptor sets whose addresses are passed in rfds, wfds, and efds to see if some of their descriptors are ready for reading, are ready for writing, or have an exceptional condition pending, respectively. For more details about the arguments and return code semantics see select(2).

  • int pth_pselect(int nfd, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timeout, const sigset_t *sigmask);

    This is a variant of the POSIX pselect(2) function, which in turn is a stronger variant of 4.2BSD select(2). The difference is that the higher-resolution struct timespec is passed instead of the lower-resolution struct timeval and that a signal mask is specified which is temporarily set while waiting for input. For more details about the arguments and return code semantics see pselect(2) and select(2).

  • int pth_poll(struct pollfd *fds, unsigned int nfd, int timeout);

    This is a variant of the SysV poll(2) function. It examines the I/O descriptors which are passed in the array fds to see if some of them are ready for reading, are ready for writing, or have an exceptional condition pending, respectively. For more details about the arguments and return code semantics see poll(2).

  • ssize_t pth_read(int fd, void *buf, size_t nbytes);

    This is a variant of the POSIX read(2) function. It reads up to nbytes bytes into buf from file descriptor fd. The difference between read(2) and pth_read(2) is that pth_read(2) suspends execution of the current thread until the file descriptor is ready for reading. For more details about the arguments and return code semantics see read(2).

  • ssize_t pth_readv(int fd, const struct iovec *iovec, int iovcnt);

    This is a variant of the POSIX readv(2) function. It reads data from file descriptor fd into the first iovcnt rows of the iov vector. The difference between readv(2) and pth_readv(2) is that pth_readv(2) suspends execution of the current thread until the file descriptor is ready for reading. For more details about the arguments and return code semantics see readv(2).

  • ssize_t pth_write(int fd, const void *buf, size_t nbytes);

    This is a variant of the POSIX write(2) function. It writes nbytes bytes from buf to file descriptor fd. The difference between write(2) and pth_write(2) is that pth_write(2) suspends execution of the current thread until the file descriptor is ready for writing. For more details about the arguments and return code semantics see write(2).

  • ssize_t pth_writev(int fd, const struct iovec *iovec, int iovcnt);

    This is a variant of the POSIX writev(2) function. It writes data to file descriptor fd from the first iovcnt rows of the iov vector. The difference between writev(2) and pth_writev(2) is that pth_writev(2) suspends execution of the current thread until the file descriptor is ready for reading. For more details about the arguments and return code semantics see writev(2).

  • ssize_t pth_pread(int fd, void *buf, size_t nbytes, off_t offset);

    This is a variant of the POSIX pread(3) function. It performs the same action as a regular read(2), except that it reads from a given position in the file without changing the file pointer. The first three arguments are the same as for pth_read(3) with the addition of a fourth argument offset for the desired position inside the file.

  • ssize_t pth_pwrite(int fd, const void *buf, size_t nbytes, off_t offset);

    This is a variant of the POSIX pwrite(3) function. It performs the same action as a regular write(2), except that it writes to a given position in the file without changing the file pointer. The first three arguments are the same as for pth_write(3) with the addition of a fourth argument offset for the desired position inside the file.

  • ssize_t pth_recv(int fd, void *buf, size_t nbytes, int flags);

    This is a variant of the SUSv2 recv(2) function and equal to ``pth_recvfrom(fd, buf, nbytes, flags, NULL, 0)''.

  • ssize_t pth_recvfrom(int fd, void *buf, size_t nbytes, int flags, struct sockaddr *from, socklen_t *fromlen);

    This is a variant of the SUSv2 recvfrom(2) function. It reads up to nbytes bytes into buf from file descriptor fd while using flags and from/fromlen. The difference between recvfrom(2) and pth_recvfrom(2) is that pth_recvfrom(2) suspends execution of the current thread until the file descriptor is ready for reading. For more details about the arguments and return code semantics see recvfrom(2).

  • ssize_t pth_send(int fd, const void *buf, size_t nbytes, int flags);

    This is a variant of the SUSv2 send(2) function and equal to ``pth_sendto(fd, buf, nbytes, flags, NULL, 0)''.

  • ssize_t pth_sendto(int fd, const void *buf, size_t nbytes, int flags, const struct sockaddr *to, socklen_t tolen);

    This is a variant of the SUSv2 sendto(2) function. It writes nbytes bytes from buf to file descriptor fd while using flags and to/tolen. The difference between sendto(2) and pth_sendto(2) is that pth_sendto(2) suspends execution of the current thread until the file descriptor is ready for writing. For more details about the arguments and return code semantics see sendto(2).


6. ¿¹Á¦

´ÙÀ½ ¿¹Á¦´Â TCP Æ÷Æ® 12345ÀÇ Á¢¼ÓÀ» ´ë±âÇÏ´Ù°¡ Á¢¼ÓÀÌ ÀϾ¸é ¼ÒÄÏ¿¡ ÇöÀç ½Ã°£À» ¾Ë·ÁÁÖ´Â ´Ü¼øÇÑ ¼­¹öÀÔ´Ï´Ù. »õ·Î¿î Á¢¼Ó¸¶´Ù ¾²·¹µå¸¦ ½ºÆùÇÕ´Ï´Ù. ±×¸®°í, ¸ÖƼ¾²·¹µùÀ» ´õ Àß º¸¿©ÁÖ±â À§Çؼ­, ¸Å 5Ãʸ¶´Ù stderr·Î ÇöÀç ½Ã°£À» Ãâ·ÂÇÏ´Â ´Ü¼øÇÑ ½Ã°£ Ç¥½Ã±â(ticker) ¾²·¹µå¸¦ µ¿½Ã¿¡ ½ÇÇàÇÕ´Ï´Ù. ÀÌ ¿¹Á¦´Â PthÀ» ¾î¶»°Ô »ç¿ëÇϴ°¡¿¡ ÁýÁßÇϱâ À§Çؼ­ ¾î¶°ÇÑ ¿À·ù °Ë»çµµ ÇÏÁö ¾Ê½À´Ï´Ù.

 /* the socket connection handler thread */
 static void *handler(void *_arg)
 {
     int fd = (int)_arg;
     time_t now;
     char *ct;
     now = time(NULL);
     ct = ctime(now);
     pth_write(fd, ct, strlen(ct));
     close(fd);
     return NULL;
 }
 /* the stderr time ticker thread */
 static void *ticker(void *_arg)
 {
     time_t now;
     char *ct;
     float load;
     for (;;) {
         pth_sleep(5);
         now = time(NULL);
         ct = ctime(now);
         ct[strlen(ct)-1] = '\0';
         pth_ctrl(PTH_CTRL_GETAVLOAD, load);
         printf("ticker: time: %s, average load: %.2f\n", ct, load);
     }
 }
 /* the main thread/procedure */
 int main(int argc, char *argv[])
 {
     pth_attr_t attr;
     struct sockaddr_in sar;
     struct protoent *pe;
     struct sockaddr_in peer_addr;
     int peer_len;
     int sa, sw;
     int port;
     pth_init();
     signal(SIGPIPE, SIG_IGN);
     attr = pth_attr_new();
     pth_attr_set(attr, PTH_ATTR_NAME, "ticker");
     pth_attr_set(attr, PTH_ATTR_STACK_SIZE, 64*1024);
     pth_attr_set(attr, PTH_ATTR_JOINABLE, FALSE);
     pth_spawn(attr, ticker, NULL);
     pe = getprotobyname("tcp");
     sa = socket(AF_INET, SOCK_STREAM, pe->p_proto);
     sar.sin_family = AF_INET;
     sar.sin_addr.s_addr = INADDR_ANY;
     sar.sin_port = htons(PORT);
     bind(sa, (struct sockaddr *)sar, sizeof(struct sockaddr_in));
     listen(sa, 10);
     pth_attr_set(attr, PTH_ATTR_NAME, "handler");
     for (;;) {
         peer_len = sizeof(peer_addr);
         sw = pth_accept(sa, (struct sockaddr *)peer_addr, peer_len);
         pth_spawn(attr, handler, (void *)sw);
     }
 }
	


7. ºôµå ȯ°æ

ÀÌ Àå¿¡¼­´Â Pth ±â¹ÝÀÇ ÇÁ·Î±×·¥À» ºôµåÇϴ ȯ°æÀ» ±¸ÃàÇϴ ǥÁØÀûÀÎ ¹æ¹ý¿¡ ´ëÇؼ­ ¼³¸íÇÕ´Ï´Ù. ¾ÆÁÖ °£´ÜÇÑ È¯°æºÎÅÍ º¹ÀâÇÑ °Í±îÁö Â÷·Ê´ë·Î ¼³¸íÇÕ´Ï´Ù.


7.1. ¼öµ¿ ºôµå ȯ°æ(ÃʱÞ)

ù¹ø° ¿¹Á¦ÀÇ ¼Ò½º ÆÄÀÏÀ» foo.c¶ó°í °¡Á¤Çϸé, ´ÙÀ½ÀÇ Makefile·Î ºôµå ȯ°æÀ» °£´ÜÇÏ°Ô ¸¸µé ¼ö ÀÖ½À´Ï´Ù.

 $ vi Makefile
 | CC      = cc
 | CFLAGS  = `pth-config --cflags`
 | LDFLAGS = `pth-config --ldflags`
 | LIBS    = `pth-config --libs`
 |
 | all: foo
 | foo: foo.o
 |     $(CC) $(LDFLAGS) -o foo foo.o $(LIBS)
 | foo.o: foo.c
 |     $(CC) $(CFLAGS) -c foo.c
 | clean:
 |     rm -f foo foo.o
		

Pth¸¦ ¼³Ä¡Çϸé ÀÖ´Â pth-config ÇÁ·Î±×·¥À» ÅëÇؼ­ ÇÊ¿äÇÑ ÄÄÆÄÀÏ·¯¿Í ¸µÄ¿ÀÇ Ç÷¡±×¸¦ ±×¶§ ±×¶§ ¾ò½À´Ï´Ù. ÀÌ Á¢±Ù¹ýÀº ¼Õ½±°Ô Á¢±ÙÇÒ ¼ö ÀÖ°í ÀÛÀº ÇÁ·ÎÁ§Æ® Àß ¸Â½À´Ï´Ù.


7.2. Autoconf ºôµå ȯ°æ(°í±Þ)

The previous approach is simple but inflexible. First, to speed up building, it would be nice to not expand the compiler and linker flags every time the compiler is started. Second, it would be useful to also be able to build against uninstalled Pth, that is, against a Pth source tree which was just configured and built, but not installed. Third, it would be also useful to allow checking of the Pth version to make sure it is at least a minimum required version. And finally, it would be also great to make sure Pth works correctly by first performing some sanity compile and run-time checks. All this can be done if we use GNU autoconf and the AC_CHECK_PTH macro provided by Pth. For this, we establish the following three files:

First we again need the Makefile, but this time it contains autoconf placeholders and additional cleanup targets. And we create it under the name Makefile.in, because it is now an input file for autoconf:

 $ vi Makefile.in
 | CC      = @CC@
 | CFLAGS  = @CFLAGS@
 | LDFLAGS = @LDFLAGS@
 | LIBS    = @LIBS@
 |
 | all: foo
 | foo: foo.o
 |     $(CC) $(LDFLAGS) -o foo foo.o $(LIBS)
 | foo.o: foo.c
 |     $(CC) $(CFLAGS) -c foo.c
 | clean:
 |     rm -f foo foo.o
 | distclean:
 |     rm -f foo foo.o
 |     rm -f config.log config.status config.cache
 |     rm -f Makefile
		

Because autoconf generates additional files, we added a canonical distclean target which cleans this up. Secondly, we wrote configure.ac, a (minimal) autoconf script specification:

 $ vi configure.ac
 | AC_INIT(Makefile.in)
 | AC_CHECK_PTH(1.3.0)
 | AC_OUTPUT(Makefile)
		

Then we let autoconf's aclocal program generate for us an aclocal.m4 file containing Pth's AC_CHECK_PTH macro. Then we generate the final configure script out of this aclocal.m4 file and the configure.ac file:

 $ aclocal --acdir=`pth-config --acdir`
 $ autoconf
		

After these steps, the working directory should look similar to this:

 $ ls -l
 -rw-r--r--  1 rse  users    176 Nov  3 11:11 Makefile.in
 -rw-r--r--  1 rse  users  15314 Nov  3 11:16 aclocal.m4
 -rwxr-xr-x  1 rse  users  52045 Nov  3 11:16 configure
 -rw-r--r--  1 rse  users     63 Nov  3 11:11 configure.ac
 -rw-r--r--  1 rse  users   4227 Nov  3 11:11 foo.c
		

If we now run configure we get a correct Makefile which immediately can be used to build foo (assuming that Pth is already installed somewhere, so that pth-config is in $PATH):

 $ ./configure
 creating cache ./config.cache
 checking for gcc... gcc
 checking whether the C compiler (gcc   ) works... yes
 checking whether the C compiler (gcc   ) is a cross-compiler... no
 checking whether we are using GNU C... yes
 checking whether gcc accepts -g... yes
 checking how to run the C preprocessor... gcc -E
 checking for GNU Pth... version 1.3.0, installed under /usr/local
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 rse@en1:/e/gnu/pth/ac
 $ make
 gcc -g -O2 -I/usr/local/include -c foo.c
 gcc -L/usr/local/lib -o foo foo.o -lpth
		

If Pth is installed in non-standard locations or pth-config is not in $PATH, one just has to drop the configure script a note about the location by running configure with the option --with-pth=dir (where dir is the argument which was used with the --prefix option when Pth was installed).


7.3. PthÀÇ º¹»çº»À¸·Î Autoconf ºôµåÇϴ ȯ°æ(Àü¹®°¡)

Finally let us assume the foo program stays under either a GPL or LGPL distribution license and we want to make it a stand-alone package for easier distribution and installation. That is, we don't want to oblige the end-user to install Pth just to allow our foo package to compile. For this, it is a convenient practice to include the required libraries (here Pth) into the source tree of the package (here foo). Pth ships with all necessary support to allow us to easily achieve this approach. Say, we want Pth in a subdirectory named pth/ and this directory should be seamlessly integrated into the configuration and build process of foo.

First we again start with the Makefile.in, but this time it is a more advanced version which supports subdirectory movement:

 $ vi Makefile.in
 | CC      = @CC@
 | CFLAGS  = @CFLAGS@
 | LDFLAGS = @LDFLAGS@
 | LIBS    = @LIBS@
 |
 | SUBDIRS = pth
 |
 | all: subdirs_all foo
 |
 | subdirs_all:
 |     @$(MAKE) $(MFLAGS) subdirs TARGET=all
 | subdirs_clean:
 |     @$(MAKE) $(MFLAGS) subdirs TARGET=clean
 | subdirs_distclean:
 |     @$(MAKE) $(MFLAGS) subdirs TARGET=distclean
 | subdirs:
 |     @for subdir in $(SUBDIRS); do \
 |         echo "===> $$subdir ($(TARGET))"; \
 |         (cd $$subdir; $(MAKE) $(MFLAGS) $(TARGET) || exit 1) || exit 1; \
 |         echo "=== $$subdir"; \
 |     done
 |
 | foo: foo.o
 |     $(CC) $(LDFLAGS) -o foo foo.o $(LIBS)
 | foo.o: foo.c
 |     $(CC) $(CFLAGS) -c foo.c
 |
 | clean: subdirs_clean
 |     rm -f foo foo.o
 | distclean: subdirs_distclean
 |     rm -f foo foo.o
 |     rm -f config.log config.status config.cache
 |     rm -f Makefile
		

Then we create a slightly different autoconf script configure.ac:

 $ vi configure.ac
 | AC_INIT(Makefile.in)
 | AC_CONFIG_AUX_DIR(pth)
 | AC_CHECK_PTH(1.3.0, subdir:pth --disable-tests)
 | AC_CONFIG_SUBDIRS(pth)
 | AC_OUTPUT(Makefile)
		

Here we provided a default value for foo's --with-pth option as the second argument to AC_CHECK_PTH which indicates that Pth can be found in the subdirectory named pth/. Additionally we specified that the --disable-tests option of Pth should be passed to the pth/ subdirectory, because we need only to build the Pth library itself. And we added a AC_CONFIG_SUBDIR call which indicates to autoconf that it should configure the pth/ subdirectory, too. The AC_CONFIG_AUX_DIR directive was added just to make autoconf happy, because it wants to find a install.sh or shtool script if AC_CONFIG_SUBDIRS is used.

Now we let autoconf's aclocal program again generate for us an aclocal.m4 file with the contents of Pth's AC_CHECK_PTH macro. Finally we generate the configure script out of this aclocal.m4 file and the configure.ac file.

 $ aclocal --acdir=`pth-config --acdir`
 $ autoconf
		

Now we have to create the pth/ subdirectory itself. For this, we extract the Pth distribution to the foo source tree and just rename it to pth/:

 $ gunzip  pth-X.Y.Z.tar.gz | tar xvf -
 $ mv pth-X.Y.Z pth
		

Optionally to reduce the size of the pth/ subdirectory, we can strip down the Pth sources to a minimum with the striptease feature:

 $ cd pth
 $ ./configure
 $ make striptease
 $ cd ..
		

After this the source tree of foo should look similar to this:

 $ ls -l
 -rw-r--r--  1 rse  users    709 Nov  3 11:51 Makefile.in
 -rw-r--r--  1 rse  users  16431 Nov  3 12:20 aclocal.m4
 -rwxr-xr-x  1 rse  users  57403 Nov  3 12:21 configure
 -rw-r--r--  1 rse  users    129 Nov  3 12:21 configure.ac
 -rw-r--r--  1 rse  users   4227 Nov  3 11:11 foo.c
 drwxr-xr-x  2 rse  users   3584 Nov  3 12:36 pth
 $ ls -l pth/
 -rw-rw-r--  1 rse  users   26344 Nov  1 20:12 COPYING
 -rw-rw-r--  1 rse  users    2042 Nov  3 12:36 Makefile.in
 -rw-rw-r--  1 rse  users    3967 Nov  1 19:48 README
 -rw-rw-r--  1 rse  users     340 Nov  3 12:36 README.1st
 -rw-rw-r--  1 rse  users   28719 Oct 31 17:06 config.guess
 -rw-rw-r--  1 rse  users   24274 Aug 18 13:31 config.sub
 -rwxrwxr-x  1 rse  users  155141 Nov  3 12:36 configure
 -rw-rw-r--  1 rse  users  162021 Nov  3 12:36 pth.c
 -rw-rw-r--  1 rse  users   18687 Nov  2 15:19 pth.h.in
 -rw-rw-r--  1 rse  users    5251 Oct 31 12:46 pth_acdef.h.in
 -rw-rw-r--  1 rse  users    2120 Nov  1 11:27 pth_acmac.h.in
 -rw-rw-r--  1 rse  users    2323 Nov  1 11:27 pth_p.h.in
 -rw-rw-r--  1 rse  users     946 Nov  1 11:27 pth_vers.c
 -rw-rw-r--  1 rse  users   26848 Nov  1 11:27 pthread.c
 -rw-rw-r--  1 rse  users   18772 Nov  1 11:27 pthread.h.in
 -rwxrwxr-x  1 rse  users   26188 Nov  3 12:36 shtool
		

Now when we configure and build the foo package it looks similar to this:

 $ ./configure
 creating cache ./config.cache
 checking for gcc... gcc
 checking whether the C compiler (gcc   ) works... yes
 checking whether the C compiler (gcc   ) is a cross-compiler... no
 checking whether we are using GNU C... yes
 checking whether gcc accepts -g... yes
 checking how to run the C preprocessor... gcc -E
 checking for GNU Pth... version 1.3.0, local under pth
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 configuring in pth
 running /bin/sh ./configure  --enable-subdir --enable-batch
 --disable-tests --cache-file=.././config.cache --srcdir=.
 loading cache .././config.cache
 checking for gcc... (cached) gcc
 checking whether the C compiler (gcc   ) works... yes
 checking whether the C compiler (gcc   ) is a cross-compiler... no
 [...]
 $ make
 ===> pth (all)
 ./shtool scpp -o pth_p.h -t pth_p.h.in -Dcpp -Cintern -M '==#==' pth.c
 pth_vers.c
 gcc -c -I. -O2 -pipe pth.c
 gcc -c -I. -O2 -pipe pth_vers.c
 ar rc libpth.a pth.o pth_vers.o
 ranlib libpth.a
 === pth
 gcc -g -O2 -Ipth -c foo.c
 gcc -Lpth -o foo foo.o -lpth
		

As you can see, autoconf now automatically configures the local (stripped down) copy of Pth in the subdirectory pth/ and the Makefile automatically builds the subdirectory, too.


8. SYSTEM CALL WRAPPER FACILITY

Pth per default uses an explicit API, including the system calls. For instance you've to explicitly use pth_read(3) when you need a thread-aware read(3) and cannot expect that by just calling read(3) only the current thread is blocked. Instead with the standard read(3) call the whole process will be blocked. But because for some applications (mainly those consisting of lots of third-party stuff) this can be inconvenient. Here it's required that a call to read(3) `magically' means pth_read(3). The problem here is that such magic Pth cannot provide per default because it's not really portable. Nevertheless Pth provides a two step approach to solve this problem:


8.1. Soft System Call Mapping

This variant is available on all platforms and can always be enabled by building Pth with --enable-syscall-soft. This then triggers some #define's in the pth.h header which map for instance read(3) to pth_read(3), etc. Currently the following functions are mapped: fork(2), nanosleep(3), usleep(3), sleep(3), sigwait(3), waitpid(2), system(3), select(2), poll(2), connect(2), accept(2), read(2), write(2), recv(2), send(2), recvfrom(2), sendto(2).

The drawback of this approach is just that really all source files of the application where these function calls occur have to include pth.h, of course. And this also means that existing libraries, including the vendor's stdio, usually will still block the whole process if one of its I/O functions block.


8.2. Hard System Call Mapping

This variant is available only on those platforms where the syscall(2) function exists and there it can be enabled by building Pth with --enable-syscall-hard. This then builds wrapper functions (for instances read(3)) into the Pth library which internally call the real Pth replacement functions (pth_read(3)). Currently the following functions are mapped: fork(2), nanosleep(3), usleep(3), sleep(3), waitpid(2), system(3), select(2), poll(2), connect(2), accept(2), read(2), write(2).

The drawback of this approach is that it depends on syscall(2) interface and prototype conflicts can occur while building the wrapper functions due to different function signatures in the vendor C header files. But the advantage of this mapping variant is that the source files of the application where these function calls occur have not to include pth.h and that existing libraries, including the vendor's stdio, magically become thread-aware (and then block only the current thread).


9. IMPLEMENTATION NOTES

Pth is very portable because it has only one part which perhaps has to be ported to new platforms (the machine context initialization). But it is written in a way which works on mostly all Unix platforms which support makecontext(2) or at least sigstack(2) or sigaltstack(2) [see pth_mctx.c for details]. Any other Pth code is POSIX and ANSI C based only.

The context switching is done via either SUSv2 makecontext(2) or POSIX make[sig]setjmp(3) and [sig]longjmp(3). Here all CPU registers, the program counter and the stack pointer are switched. Additionally the Pth dispatcher switches also the global Unix errno variable [see pth_mctx.c for details] and the signal mask (either implicitly via sigsetjmp(3) or in an emulated way via explicit setprocmask(2) calls).

The Pth event manager is mainly select(2) and gettimeofday(2) based, i.e., the current time is fetched via gettimeofday(2) once per context switch for time calculations and all I/O events are implemented via a single central select(2) call [see pth_sched.c for details].

The thread control block management is done via virtual priority queues without any additional data structure overhead. For this, the queue linkage attributes are part of the thread control blocks and the queues are actually implemented as rings with a selected element as the entry point [see pth_tcb.h and pth_pqueue.c for details].

Most time critical code sections (especially the dispatcher and event manager) are speeded up by inline functions (implemented as ANSI C pre-processor macros). Additionally any debugging code is completely removed from the source when not built with -DPTH_DEBUG (see Autoconf --enable-debug option), i.e., not only stub functions remain [see pth_debug.c for details].


10. RESTRICTIONS

Pth (intentionally) provides no replacements for non-thread-safe functions (like strtok(3) which uses a static internal buffer) or synchronous system functions (like gethostbyname(3) which doesn't provide an asynchronous mode where it doesn't block). When you want to use those functions in your server application together with threads, you've to either link the application against special third-party libraries (or for thread-safe/reentrant functions possibly against an existing libc_r of the platform vendor). For an asynchronous DNS resolver library use the GNU adns package from Ian Jackson ( see http://www.gnu.org/software/adns/adns.html ).


11. HISTORY

The Pth library was designed and implemented between February and July 1999 by Ralf S. Engelschall after evaluating numerous (mostly preemptive) thread libraries and after intensive discussions with Peter Simons, Martin Kraemer, Lars Eilebrecht and Ralph Babel related to an experimental (matrix based) non-preemptive C++ scheduler class written by Peter Simons.

Pth was then implemented in order to combine the non-preemptive approach of multithreading (which provides better portability and performance) with an API similar to the popular one found in Pthread libraries (which provides easy programming).

So the essential idea of the non-preemptive approach was taken over from Peter Simons scheduler. The priority based scheduling algorithm was suggested by Martin Kraemer. Some code inspiration also came from an experimental threading library (rsthreads) written by Robert S. Thau for an ancient internal test version of the Apache webserver. The concept and API of message ports was borrowed from AmigaOS' Exec subsystem. The concept and idea for the flexible event mechanism came from Paul Vixie's eventlib (which can be found as a part of BIND v8).


12. BUG REPORTS AND SUPPORT

If you think you have found a bug in Pth, you should send a report as complete as possible to bug-pth@gnu.org. If you can, please try to fix the problem and include a patch, made with 'diff -u3', in your report. Always, at least, include a reasonable amount of description in your report to allow the author to deterministically reproduce the bug.

For further support you additionally can subscribe to the pth-users@gnu.org mailing list by sending an Email to pth-users-request@gnu.org with `subscribe pth-users' (or `subscribe pth-users address' if you want to subscribe from a particular Email address) in the body. Then you can discuss your issues with other Pth users by sending messages to pth-users@gnu.org. Currently (as of August 2000) you can reach about 110 Pth users on this mailing list. Old postings you can find at http://www.mail-archive.com/pth-users@gnu.org/.


13. SEE ALSO


13.1. Related Web Locations

`comp.programming.threads Newsgroup Archive', http://www.deja.com/topics_if.xp?search=topicgroup=comp.programming.threads

`comp.programming.threads Frequently Asked Questions (F.A.Q.)', http://www.lambdacs.com/newsgroup/FAQ.html

`Multithreading - Definitions and Guidelines', Numeric Quest Inc 1998; http://www.numeric-quest.com/lang/multi-frame.html

`The Single UNIX Specification, Version 2 - Threads', The Open Group 1997; http://www.opengroup.org/onlinepubs /007908799/xsh/threads.html

SMI Thread Resources, Sun Microsystems Inc; http://www.sun.com/workshop/threads/

Bibliography on threads and multithreading, Torsten Amundsen; http://liinwww.ira.uka.de/bibliography/Os/threads.html


13.2. Related Books

B. Nichols, D. Buttlar, J.P. Farrel: `Pthreads Programming - A POSIX Standard for Better Multiprocessing', O'Reilly 1996; ISBN 1-56592-115-1

B. Lewis, D. J. Berg: `Multithreaded Programming with Pthreads', Sun Microsystems Press, Prentice Hall 1998; ISBN 0-13-680729-1

B. Lewis, D. J. Berg: `Threads Primer - A Guide To Multithreaded Programming', Prentice Hall 1996; ISBN 0-13-443698-9

S. J. Norton, M. D. Dipasquale: `Thread Time - The Multithreaded Programming Guide', Prentice Hall 1997; ISBN 0-13-190067-6

D. R. Butenhof: `Programming with POSIX Threads', Addison Wesley 1997; ISBN 0-201-63392-2


13.3. Related Manpages

pth-config(1), pthread(3). getcontext(2), setcontext(2), makecontext(2), swapcontext(2), sigstack(2), sigaltstack(2), sigaction(2), sigemptyset(2), sigaddset(2), sigprocmask(2), sigsuspend(2), sigsetjmp(3), siglongjmp(3), setjmp(3), longjmp(3), select(2), gettimeofday(2).


14. AUTHOR

Ralf S. Engelschall

rse(at)engelschall.com

www.engelschall.com

Please send FSF GNU inquiries questions to gnu(at)gnu.org.

There are also other ways to contact the FSF.

Please send comments on these web pages to webmasters(at)gnu.org, send other questions to gnu(at)gnu.org.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Copyright 1999-2002 Ralf S. Engelschall rse(at)gnu.org>

Last Modified: 2001-02-13 02:08:27


ID
Password
Join
True happiness will be found only in true love.


sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2005-09-07 16:46:26
Processing time 0.0026 sec